Hi Christophe (and others interested in cleancache progress) --
Thanks for taking some time to talk with me about cleancache
at LSF summit! You had some interesting thoughts and suggestions
that I said I would investigate. They are:
1) use inode kva as key instead of i_ino
2) eliminate cleancache shim and call zcache directly
3) fs's requiring key > inode_t (e.g. 64-bit-fs on 32-bit-kernel)
4) eliminate fs-specific code entirely (e.g. "opt-in")
5) eliminate global variable
Here's my conclusions:
1) You suggested using the inode kva as a "key" for cleancache.
I think your goal was to make it more fs-independent and also
to eliminate the need for using a per-fs enabler and "pool id".
I looked at this but it will not work because cleancache
retains page cache data pages persistently even when the
inode has been pruned from the inode_unused_list and only
flushes the data pages if the file gets removed/truncated. If
cleancache used the inode kva, there would be coherency issues
when the inode kva is reused. Alternately, if cleancache
flushed the pages when the inode kva was freed, much of
the value of cleancache would be lost because the cache
of pages in cleancache is potentially much larger than
the page cache and is most useful if the pages survive
inode cache removal.
If I misunderstood your proposal or if you disagree, please
let me know.
2) You suggested eliminating the cleancache shim layer and just
directly calling zcache, effectively eliminating Xen as
a user. During and after LSF summit, I talked to developers
from Google who are interested in investigating the cleancache
interface for use with cgroups, an IBM developer who was
interested in cleancache for optimizing NUMA, and soon I
will be talking to HP Labs about using it as an interface
for "memory blades". I also think Rik van Riel and Mel Gorman
were intrigued about its use for collecting better memory
utilization statistics ...
