| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: RFC -- new zone type
> From: Larry Bassel [mailto:lbassel@xxxxxxxxxxxxxx]
>
> As this area must be very large and contiguous, I can't use kmalloc or similar
> allocation APIs -- I imagine I'll carve it out early in boot with
> memblock_remove() -- luckily this area is of fixed size. If this memory
> were in ZONE_HIGHMEM, I'd just have to use kmap to get a temporary mapping
> to use when the page is copied to or from "normal" system memory (or am
> I missing something here?). Whether this area is in highmem or not, I imagine
> I'll need to write an allocator to allocate/free pages from the "dual-purpose"
> memory when it is cleancache.
Yep. It would also be very nice if you could allocate the
metadata (tmem data structures) from the same "dual-purpose"
memory as then all of the data structures can simply be discarded
when you need the memory for the "big-100MB-block" purpose.
Zeroing a single pointer would be enough to "free" all
data and metadata.
Sadly I don't think this will work when the dual-purpose memory
is in highmem... you will need to walk the metadata and
free it all up when you free the cleancache pages.
> > I did write a patch a while back that allows xvmalloc to use highmem
> > pages in it's storage pool. Although, from looking at the history of this
> > conversation, you'd be writing a different backend for tmem and not using
> > zcache anyway.
>
> We're going to want a backend which is (at least to a
> first approximation) a simplification of zcache
> -- no compression and no frontswap is needed.
> Possibly we'll start with zcache and remove things we don't need.
Agree that's your best bet. Let us know how it goes, especially if
you eventually plan for the driver to be submitted upstream.
> > Currently the tmem code is in the zcache driver. However, if there are
> > going to be other backends designed for it, we may need to move it into its
> > own module so it can be shared.
I think the longterm home for tmem.c/tmem.h should be in the "lib"
subdirectory of the linux tree, but it will require another driver
or two to use it before the linux maintainers will consider that.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home