search

mfrw / compcache

Automatically exported from code.google.com/p/compcache
0 stars 0 forks source link

We should change the handling behavior of incompressible swap-out when backing swap is present #75

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
First of all, thanks to all the developers and contributors who have created 
and maintained this amazing software until now.
In advance to talking, let me apologize for my novice English skill. Whatever 
sounds like offending or harassing or any kind of rude in my words, isn't meant 
that.
Also I'm just another noob to Linux kernel module development. So if anything 
make you confused in what I'm going to talk, please tolerate that.

Since I came to know compcache yesterday, I've applied it on my kernel, tried 
several configuration and looked into its behavior, and so far it looks to be 
working fine, and the result was  just amazing. My laptop with only 256MB RAM 
turned into almost like with double of it, running my GNOME desktop much 
faster. Such a great work.

Before I started I'd done a small research on it and found that there're 2 
typical usage of compcache, using compcache with its built-in backing swap, or 
with Linux swap at a time.
Well, some people wrote on the web that it's better to use backing swap rather 
compared to using compcache with Linux swap, because that way compcache can 
potentially manage swapped pages in hard drive somehow in better way, so I 
followed what they suggested, but eventually noticed something disappointing to 
me happens when the option backing_swap is present. It's noticeably slower than 
combined compcache and Linux swap. Actually I had to spend much time waiting 
compcache still swap in-and-out my hard drive.

No much time were needed though, to locate the cause of the problem. According 
to 'man compcache' when a requested page for swap-out is incompressible with 
LZO, then compcache tries to store it to the backing swap if present.
Here's my opinion; But... should compcache do so?
If my sense is not far off the ordinary, people use compcache because they want 
to avoid slowdown caused by thrashing, not because they want to double the 
memory.
I heard that compcache's philosophy is because compressing/decompressing a data 
with LZO is much faster than writing/reading it in external storages, use RAM 
to store the compressed data. Available memory increasing is only a side effect.

So, I compiled a copy of compcache with a small revision; it won't try to swap 
out incompressible pages to backing swap; and tried how it works. The result 
was very satisfying, no access on backing swap until RAM exhausted, making it 
much faster.

My story ends, and here's one proposal.
Why don't we consider to change the handling behavior of incompressible 
swap-out so unnecessary thrashing would happen with compcache?

Thank you.

Information for whom it may matter:
compcache 0.6.2
linux 2.6.31

Lizard <firelzrd@gmail.com>

Original issue reported on code.google.com by firel...@gmail.com on 14 Oct 2010 at 1:05

GoogleCodeExporter commented 9 years ago 
a small addition; my point is that until the RAM is really fulfilled, no matter 
well-compressed or not, pages should stay in the RAM not the hard drive because 
hard drive access ruins compcache's advantage that is avoidance of slowdown.

thank you.

Original comment by firel...@gmail.com on 14 Oct 2010 at 1:18

GoogleCodeExporter commented 9 years ago 
Merging with issue #81. Not exactly a duplicate but just to have once place to 
track this feature.

Original comment by nitingupta910@gmail.com on 2 Oct 2012 at 10:25