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

[Larry Bassel <lbassel@xxxxxxxxxxxxxx>]

On 07 Oct 11 11:01, Seth Jennings wrote:
> On 10/07/2011 10:23 AM, Dan Magenheimer wrote:
> >> From: Larry Bassel [mailto:lbassel@xxxxxxxxxxxxxx]
> >> Sent: Thursday, October 06, 2011 5:04 PM
> >> To: Dan Magenheimer
> >> Cc: Larry Bassel; linux-mm@xxxxxxxxx; Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> Subject: Re: [Xen-devel] Re: RFC -- new zone type
> >>
> >> Thanks for your answers to my questions. I have one more:
> >>
> >> Will there be any problem if the memory I want to be
> >> transcendent is highmem (i.e. doesn't have any permanent
> >> virtual<->physical mapping)?
> 
> I guess I need to make the distinction between tmem, the transcendent
> memory layer, and zcache, a tmem backend that does the compression
> and storage work.  Tmem is highmem agnostic.  It's just passing the
> page information through to the backend, zcache.

I'm sorry if my question was ambiguous -- I want to use the
"cleancache" concept to allow us to have a large (> 100M) piece
of contiguous physical memory which can either be used as
such or otherwise used as a cleancache for discardable pages.
It is this memory that I'm asking if it can be highmem.
> 
> Zcache can store data stored in highmem pages (after the patch that Dan
> referred to), but can't use highmem pages in it's own storage pools.  Both
> zbud (storage for compressed ephemeral pages) and xvmalloc (storage for
> compressed persistent pages) don't set __GFP_HIGHMEM in their page
> allocation calls because they return the virtual address of the page to
> zcache.  Since highmem pages have no virtual address expect for the short
> time they are mapped, this prevents highmem pages from being used by zbud
> and xvmalloc.

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.

> 
> 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.
> 
> 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.
> 
> --
> Seth
> 

Larry

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

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