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

Von Fugal von at fugal.net
Thu Dec 23 11:34:22 MST 2010


<quote name="John McCabe-Dansted" date="Thu, 23 Dec 2010 at 15:50 +0800">
> On Thu, Dec 23, 2010 at 2:52 AM, Von Fugal <von at fugal.net> wrote:
> > It really should sit as an in-between swap and memory place. Recently
> > "swapped" pages should go straight to compcache, evicting pages if
> > necessary *from* compcache to disk. That would be ideal. I don't know if
> > the kernel devs would ever want to futz with the kernel that much,
> > though.
> 
> Compcache is a module that can be compiled by itself, so it doesn't
> really need to be accepted by the Kernel devs. The real issue is
> whether anyone (e.g the author of compcache) will find time to do
> this.

What I was referring to was that it seems there might need to be
additional kernel functionality to achieve this in-between not quite
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
itself(compcache) to actually keep that space available for new swaps.
It seems though with any tiered cache system, the kernel should be
actively moving less used pages down the hierarchy to put recently used
pages in the higher priority caches anyway... The existence of
prioritized caches would seem to imply that, though if the compcache
"fills up" and becomes unavailable to new recent swaps, that would imply
the opposite.

> > 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. ;)
-- 
Von Fugal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://plug.org/pipermail/plug/attachments/20101223/495b166c/attachment.bin 


More information about the PLUG mailing list