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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>