| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: RFC -- new zone type
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.
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.
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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home