[linux-mm-cc] Hi All

[IKEDA, Munehiro]

Hello,

Nitin Gupta wrote:
>>> We are interested in knowing the current stage of the project. Could you
>> refer us to the latest documentation and/or code-base of the project?
>> Anything else which you think we should look at ?
>>
>> I suspect that you can get this information from Nitin. Actually, I
>> believe we need more tests on latest Ikeda's patches
>> which implemented a shrink operation to CCache. You can find this mail
>> thread here:
>> http://lists.laptop.org/pipermail/linux-mm-cc/2007-July/000165.html
> 
> 
> There are few reasons why I am not very much willing to extend/improve
> existing 2.6.x patches:

I agree that we shouldn't tweak existing code much further and I 
probably understand what Nittin wants to do.
So please consider my descriptions blow as just FYI to clarify things.


> 1) Existing approach has big metadata overhead. Ikeda's patches increases it
> further (though, I think, it was necessary for his dynamic ccache resizing
> work).

Actually it is necessary for dynamic ccache resizing.  But it is not 
only for it, but also for preventing compressed page cache data 
(fs-backed-ccache) from beeing stored eternally in ccache.
We can't free fs-backed-ccache without address-space-object-pointer 
(page->mapping) unless accessing.  Thus, chunk_head without mapping 
member trigers a kind of memory-leaking.  It is a BUG as long as ccache 
handles fs-backed pages.

It is needeless to say that mapping member is unnecessary for anonymous 
pages, because it is always swapper_space.


> 2)  It compresses both page-cache and swap-cache pages. Anderson and co.
> have shown in paper (link below) that for embedded devices only swap-cache
> pages need to be compressed. This can result in significant simplifications
> in existing code. Also, I think ccahing is mainly useful for embedded
> devices only and not much for desktop/server systems.
> 3) Its storage structure for compressed pages has some problems (large
> metada, poor locality for compressed data chunks, etc.)

I agree.


> 4) It decompresses page in context where we cannot sleep in general (like in
> find_get_page() and friends). This is a serious drawback since we need to
> allocate some temporary memory in decompression path also which we cannot
> allow to sleep and thus has very high chances of failing - If decompression
> path fails, we loose data and what not!

Why cannot we sleep?  The context is basically same as swap-in, which 
may sleep the context.
In fact, my patch can make the context sleep and works well.


Well, I found 2 bugs after my last submitting.
If, only if, you want to evaluate 2.6.21-based ccache, please download 
patches from the link
"ccache_avoid-oom_v3.tar.bz2"
on
http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree16

I'm glad if that helps.

Best regards,
IKEDA, Munehiro