[linux-mm-cc] [PATCH 00/12] Avoid OOM-Killer with Ccache (V2)

[IKEDA Munehiro]

Hi Nitin,
Thank you for the comment.

Nitin Gupta wrote:
> Hi,
> 
> Thanks for these patches. Currently I am unable to look into these patches
> in detail however I will get to them very soon.
> 
> However, we now aim ccaching for (typically swapless) embedded devices
> _only_ since it has IMHO lost its significance on desktop/server systems.

I agree.


> So, we no longer require page-cache compression since reading from flash
> storage is fast.

Yes, this dicision seems better.
Actually, though the patches mainly modifies page-cache related code, my 
focusing point for ccache is not page-cache but anonymous pages.
The logic to write the patches is:

want to evaluate/enhance anon-page ccache
   OOM-Killer often runs
     --> NEED TO AVOID OOM-KILLER FIRST

So, compressed page-cache wasting mechanism is JUST method to avoid 
OOM-Killer, which is the fatal issue.  It's NOT the purpose.


> Only anonymous page compression is now required because of
> slow write speeds on flash devices and wear levelling issue. We do not even
> require capability to move compressed anon pages to swap as real swap does
> not even exist on typical embedded devices (or do not want to swap to flash
> storage because of above reasons).

I hafly agree.
It is the fact that wear levelling issue is the hurdle to use flash 
device as a swap device.  But on the other hand, it is also fact that 
some embedded developers have motivation to use flash as a swap device 
nowadays.  Because the cost per a byte of flash is getting lower and 
lower and now it is cheaper than DRAM.
As you know, embedded devices are always exposed strong cost pressure.


> Considering above, we can think of many simplifications to existing ccaching
> code which will make it much more light weight and much more suitable for
> inclusion in mainline.

Simplicity is preferable.  Great.
And please note the situation about flash and swap described above.  If 
ccache could be a layer between RAM and swap and compressed data could 
be swaped out, it could enhance memory efficiency, performance, and even 
cost.  It would be a great functionality for them.
(Current ccache is NOT between RAM and swap, but a virtual swap)


> So, currently I am working on a new allocator that significantly reduces
> metadata overhead and should give better performance! I will try to keep it
> generic enough to be included in mainline without any references to
> ccaching. If this allocator goes mainline and with LZO now already there,
> ccache project will reduce to simple use of exported APIs and much more
> likely to be included in mainline.
> 
> I will try and post prototype code for above and new roadmap soon and then
> we can collaborate on that :)

I'm strongly looking forward to it.


Best regards,
IKEDA, Munehiro