On 29 Sep 11 09:38, Dan Magenheimer wrote:

quoted

From: Sameer Pramod Niphadkar [mailto:spniphadkar@gmail.com]
Sent: Thursday, September 29, 2011 12:08 AM
To: Larry Bassel
Cc: linux-mm@kvack.org; vgandhi@codeaurora.org; Xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: RFC -- new zone type

On Wed, Sep 28, 2011 at 11:39 PM, Larry Bassel [off-list ref] wrote:

quoted

We need to create a large (~100M) contiguous physical memory region
which will only be needed occasionally. As this region will
use up 10-20% of all of the available memory, we do not want
to pre-reserve it at boot time. Instead, we want to create
this memory region "on the fly" when asked to by userspace,
and do it as quickly as possible, and return it to
system use when not needed.

AFAIK, this sort of operation is currently done using memory
compaction (as CMA does for instance).
Alternatively, this memory region (if it is in a fixed place)
could be created using "logical memory hotremove" and returned
to the system using "logical memory hotplug". In either case,
the contiguous physical memory would be created via migrating
pages from the "movable zone".

The problem with this approach is that the copying of up to 25000
pages may take considerable time (as well as finding destinations
for all of the pages if free memory is scarce -- this may
even fail, causing the memory region not to be created).

It was suggested to me that a new zone type which would be similar
to the "movable zone" but is only allowed to contain pages
that can be discarded (such as text) could solve this problem,
so that there is no copying or finding destination pages needed (thus
considerably reducing latency).

If I read the above correctly, you are talking about indeed
pre-reserving your ~100MB contiguous chunk of memory but using
it for "discardable" pages only, then discarding all of those
pages when you need the memory region, then going back to using
the contiguous chunk for discardable pages, and so on.

Yes, that is exactly what we want to do.

You may be interested in the concept of "ephemeral pages"
introduced by transcendent memory ("tmem") and the cleancache
patchset which went upstream at 3.0.  If you write a driver
(called a "backend" in tmem language) that accepts pages
from cleancache, you would be able to use your 100MB contiguous
chunk of memory for clean pagecache pages when it is not needed
for your other purposes, easily discard all the pages when
you do need the space, then start using it for clean pagecache
pages again when you don't need it for your purposes anymore
(and repeat this cycle as many times as necessary).

You maybe could call your driver "cleanzone".

Zcache (also upstream in drivers/staging) does something like
this already, though you might not want/need to use compression
in your driver.  In zcache, space reclaim is driven by the kernel
"shrinker" code that runs when memory is low, but another trigger
could easily be used.  Also there is likely a lot of code in
zcache (e.g. tmem.c) that you could leverage.

For more info, see: 
http://lwn.net/Articles/454795/
http://oss.oracle.com/projects/tmem 

Thanks very much, I'll look into these.

I'd be happy to answer any questions if you are still interested
after you have read the above documentation.

Thanks,
Dan

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@kvack.org.  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@kvack.org"> email@kvack.org </a>