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