Re: [RFC] Structure in Compressed Cache

["Rodrigo S. de Castro" <rodsc@bigfoot.com>]

On Tue, Oct 31, 2000 at 02:06:08PM -0200, Marcelo Tosatti wrote:
> On Mon, 30 Oct 2000, Rodrigo S. de Castro wrote:
> > 	In my implementation of compressed cache (kernel 2.2.16), I
> > started the project having my cache as a slab cache, structure
> > provided by kernel. I have all step 1 (a cache with no compression)
> > done, but I had a problem with marking pages in my cache. After an
> > email sent to the list about this subject, I started looking at shared
> > memory mechanism (mainly ipc/shm.c), and I saw that there's another
> > way of making it: with a page table allocation and memory mapping. I
> > could go on with my initial idea (with slab cache) but I think that
> > doing the latter way (with page table and memory mapping) would be
> > more complete (and, of course, harder). I will have a pool of
> > (compressed) pages that gotta be always in memory and will be
> > "between" physical memory and swap. As the project is growing I would
> > like to define now which path to follow, taking in account
> > completeness and upgradeability (to future versions of kernel). Which
> > way do you think that is better? Please, I also ask you to tell me in
> > case you know if there's another way, maybe better, of doing it.
> 
> Slab cache memory is physically contiguous and non swappable, so it may be
> a waste to use it to cache userspace data. 

	Data in slab cache is not supposed to be swapped. Currently,
the slab cache stores only a structure with some information (such as
task, original pte) and a pointer to a physical page that is allocated
at the beginning of my compressed_init() function. I manage, when
cache fills up, to swap data present in slab cache. It will be user
data (every data that may be swapped), but it will managed by our
functions. It seemed to me that a page table (with memory mapping)
would be a better choice to put all compressed levels in the same
"level" as shared pages, for example, and it seemed to be more
complete. What do you think? I hope I haven't said something too
wrong. :-)
	Would I have problem with slab cache when it grows and
shrinks, in one advanced phase of our project, due to have contiguous
data? I couldn't notice this problem when I read some papers about
slab cache, but I am not sure as well.
	Slab cache was our first choice because it allowed this
dynamism (growing and shrinking) with no big effort. In the case of
having a page table, we must have all engine built to support this
feature.

Thank you very much for your help,
-- 
Rodrigo S. de Castro   <rcastro@linux.ime.usp.br>
University of Sao Paulo - Brazil
Compressed Caching - http://tutu.ime.usp.br


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/