How to optimize a RAM-only (swapless) system?

John McCabe-Dansted gmatht at gmail.com
Thu Dec 23 21:01:58 MST 2010


On Fri, Dec 24, 2010 at 2:34 AM, Von Fugal <von at fugal.net> wrote:
> <quote name="John McCabe-Dansted" date="Thu, 23 Dec 2010 at 15:50 +0800">
> swap not quite ram place to put the compcache. I suppose you could code
> compcache to keep a certain margin open by itself initiating evictions
> when the threshold is passed. I wonder though how it would convince the
> kernel to store the evicted page into disk cache instead of

The plan is to present a single virtual swap device to the kernel, and
pass the physical swap device as an argument to the compcache module.
The kernel proper knows nothing about the physical swap device, it
just sends everything to the compcache device. The compcache device
uses some heuristic to determine which pages to store in RAM and which
to store on disk.

>> > I wonder why nobody has done compression on regular swap yet. I mean,
>> > the HUGE downside of swap is disk time, compressing the data on the disk
>> > would at least marginally speed up access time to that swapped data.
>>
>> I am guessing that the benefit is considered to be so small as to be irrelevant:
>>
>> Seek time: ~10ms
>> Time to read 4K: ~0.05ms
>> Time to read 1K: ~0.01ms
>
> Yeah, I thought it might be something like this. I didn't think it
> through thoroughly. In my defense I *did* say "marginally" to mitigate
> such an oversight. ;)

Well, I was thinking that compression may be useful, adjacent pages
may be more likely to be accessed together, so read-ahead may help.
The compression may reduce the time required to read the extra pages,
and reduce the amount of memory wasted by reading unused pages.

However it would considerable complexity, as e.g. pages would no
longer be 4K aligned and you'd have to worry about fragmentation of
the swap space. It is not clear when/if it would lead to any real
performance advantage.

-- 
John C. McCabe-Dansted


More information about the PLUG mailing list