[linux-mm-cc] Hi All
m-ikeda at ds.jp.nec.com
Tue Sep 25 06:55:24 EDT 2007
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:
> 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
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.)
> 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
I'm glad if that helps.
More information about the linux-mm-cc