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
|
Home