[lc-devel] Re: Compressed Cache time !

[Rodrigo S de C. <ro...@te...>]

Hi Nitin,

On Wednesday 21 December 2005 13:43, you wrote:
> The exams are now nearly over and I can now work full time on
> Compressed Cache :). Thanks for adding me as a developer in this
> project!

Good news! Welcome as a new developer :-) I still don't have news about the 
chances to get back to the project, and I also ended up starting a new 
project in the last weeks that is very time consuming. But I still intend to 
help you as soon as start coding.

> I've just started looking at VMM code and your previous
> implementation. Now, I am working on collecting all the things done up
> to now and making up a general workflow for this work (I'll post it
> very soon).

Great!

> Also, I have very little experience working with CVS and it appears to
> be a complex tool. So, it can take me some time to get working
> smoothly with online repository. So, also learning CVS to get some
> hang of it. Sorry, I can see here some trouble for you :).

CVS is easy. Most of time you will use update and commit only. Check CVSBook 
(google it) for more information about development with cvs.

> While reading your code, I just noticed that you have also made
> changes outside mm/ like in fs/inode.c, fs/smbfs/dir.c and some others
> in fs/. Did the implementation required changes to other kernel parts
> which had to do something with caches? I don't even know what is being
> done but just thought it would be nightmare to maintain it if it
> requires changes all over the kernel. Maybe, I haven't understood your
> idea there. I think, compressed cache should be completely transparent
> to rest to kernel subsystems.

Some kernel parts perform part of memory management (in particular eviction or 
flushing path) and we need to change them. That is particularly true for a 
compressed cache that stores any page from page cache (and not only swap 
backed ones). 

I took a brief look at the code and it doesn't seem to have many changes 
though, basicaly only to flush given compressed pages from the compressed 
cache. I can't remember at this moment why I did it, but probably there is a 
very sensible reason based on the implemented architecture.

> Also, do you think we need to work out a way to actually store huge
> pages in compressed cache. ? I currently only have a little intuitive
> understanding of impact of compressed cache on other caches but I
> think, after some initial development we will be able to take benefit
> of many things 2.6 kernels offer.

Since the user must reserve a space prior to using huge pages, it doesn't seem 
we have to worry much about it. Maybe we could try to shrink the cache if the 
user requests more huge pages or have some other policy to avoid introducing 
impact for applications that use huge pages.

As Dilma mentioned, I also had the feeling that huge page support is in its 
infancy yet, but maybe in the future a better support for them would make us 
rethink about our support in compressed cache.

Best regards,
-- 
Rodrigo S. de Castro
ro...@te...
8301-5944