linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Larry Bassel <lbassel@codeaurora.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: linux-mm@kvack.org, Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re: RFC -- new zone type
Date: Wed, 5 Oct 2011 09:56:43 -0700	[thread overview]
Message-ID: <20111005165643.GE7007@labbmf-linux.qualcomm.com> (raw)
In-Reply-To: <c2d9add1-0095-4319-8936-db1b156559bf@default>

On 29 Sep 11 09:38, Dan Magenheimer wrote:
[snip]
> 
> 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 
> 
> I'd be happy to answer any questions if you are still interested
> after you have read the above documentation.

It appears that ephemeral tmem ("cleancache") is at least
close to meeting our needs. We won't need to
have virtualization or compression.

I do have some questions (I've read the references
you included in your email to me last week and a few
of the links from the "project transcendent memory" one, but have
not looked at any of the source yet):

1. Is it currently possible to specify the size of tmem
(as for us it must be convertable into a large contiguous physical
block of specified size)? Is is currently possible to specify
the start of tmem? Are there any alignment constraints on
the start or size?

2. How does one "turn on" and "turn off" tmem (the memory
which tmem uses may also be needed for the large contiguous
memory block, or perhaps may be powered off entirely)?
Is it simply that one always answers "no" for both
get and put requests when it is "off"?

3. How portable is the tmem code? This needs to run
on an ARM system.

4. Apparently hooks are needed in the filesystem code --
which filesystems are currently supported to be used with
tmem? Is it difficult to add hooks for filesystems
that aren't yet supported?

5. There are no dependencies on memory compaction
or memory hotplug (or sparsemem), correct?

Thank you for suggesting tmem and thanks in
advance for answering my questions.

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

  parent reply	other threads:[~2011-10-05 16:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-28 18:09 RFC -- new zone type Larry Bassel
2011-09-29  6:07 ` Sameer Pramod Niphadkar
2011-09-29 16:38   ` [Xen-devel] " Dan Magenheimer
2011-09-29 17:00     ` Larry Bassel
2011-10-05 16:56     ` Larry Bassel [this message]
2011-10-05 19:43       ` Dan Magenheimer
2011-10-06 23:03         ` Larry Bassel
2011-10-07 15:23           ` Dan Magenheimer
2011-10-07 16:01             ` Seth Jennings
2011-10-07 17:19               ` Larry Bassel
2011-10-12 22:20                 ` Dan Magenheimer
2011-09-29 20:19 ` Andi Kleen
2011-09-30 17:01   ` Larry Bassel
     [not found] <20110928180909.GA7007@labbmf-linux.qualcomm.comCAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com>
     [not found] ` <c2d9add1-0095-4319-8936-db1b156559bf@default20111005165643.GE7007@labbmf-linux.qualcomm.com>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111005165643.GE7007@labbmf-linux.qualcomm.com \
    --to=lbassel@codeaurora.org \
    --cc=Xen-devel@lists.xensource.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).