WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: RFC -- new zone type

> > You may be interested in the concept of "ephemeral pages"
> > introduced by transcendent memory ("tmem") and the cleancache
> > patchset which went upstream at 3.0.  If you write a driver
> > (called a "backend" in tmem language) that accepts pages
> > from cleancache, you would be able to use your 100MB contiguous
> > chunk of memory for clean pagecache pages when it is not needed
> > for your other purposes, easily discard all the pages when
> > you do need the space, then start using it for clean pagecache
> > pages again when you don't need it for your purposes anymore
> > (and repeat this cycle as many times as necessary).
> >
> > You maybe could call your driver "cleanzone".
> >
> > Zcache (also upstream in drivers/staging) does something like
> > this already, though you might not want/need to use compression
> > in your driver.  In zcache, space reclaim is driven by the kernel
> > "shrinker" code that runs when memory is low, but another trigger
> > could easily be used.  Also there is likely a lot of code in
> > zcache (e.g. tmem.c) that you could leverage.
> >
> > For more info, see:
> > http://lwn.net/Articles/454795/
> > http://oss.oracle.com/projects/tmem
> >
> > I'd be happy to answer any questions if you are still interested
> > after you have read the above documentation.
> 
> It appears that ephemeral tmem ("cleancache") is at least
> close to meeting our needs.

Yes, I thought so also,

> We won't need to
> have virtualization or compression.

Right.  Those just demonstrate different interesting uses
of tmem/cleancache.

> I do have some questions (I've read the references
> you included in your email to me last week and a few
> of the links from the "project transcendent memory" one, but have
> not looked at any of the source yet):
> 
> 1. Is it currently possible to specify the size of tmem
> (as for us it must be convertable into a large contiguous physical
> block of specified size)? Is is currently possible to specify
> the start of tmem? Are there any alignment constraints on
> the start or size?

Your "cleanzone" driver would have complete control over
this so there would be no constraints unless you (or
generic kernel code) choose to enforce them.

> 2. How does one "turn on" and "turn off" tmem (the memory
> which tmem uses may also be needed for the large contiguous
> memory block, or perhaps may be powered off entirely)?
> Is it simply that one always answers "no" for both
> get and put requests when it is "off"?

That's right.  However, you must ensure that stale data
isn't get'able after you've turned if off and then on again.
I don't think you'll need to do that... I think you
will be assuming all of the cleancache data is gone
(not preserved).

> 3. How portable is the tmem code? This needs to run
> on an ARM system.

I don't think there is any reason it wouldn't be portable.
If you are running on a system with a 32-bit pointer
but >4GB memory (e.g. "highmem"), that might add some
complexity, but I think those problems have now been
solved in zcache so should be solveable for cleanzone
also.

> 4. Apparently hooks are needed in the filesystem code --
> which filesystems are currently supported to be used with
> tmem? Is it difficult to add hooks for filesystems
> that aren't yet supported?

The hooks are currently in ext3, ext4, btrfs, and ocfs2.
If the filesystem is "well behaved" the support is easy
to add.

> 5. There are no dependencies on memory compaction
> or memory hotplug (or sparsemem), correct?

No dependencies.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel