From: Sameer Pramod Niphadkar <spniphadkar@gmail.com>
To: Larry Bassel <lbassel@codeaurora.org>
Cc: linux-mm@kvack.org, vgandhi@codeaurora.org,
Xen-devel@lists.xensource.com
Subject: Re: RFC -- new zone type
Date: Thu, 29 Sep 2011 11:37:46 +0530 [thread overview]
Message-ID: <CAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com> (raw)
In-Reply-To: <20110928180909.GA7007@labbmf-linux.qualcomm.com>
On Wed, Sep 28, 2011 at 11:39 PM, Larry Bassel <lbassel@codeaurora.org> wrote:
> 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).
>
Is this approach similar to Copy-on-Write being used in most page
sharing entitlements ? If yes, then it almost depends on the # of
writes made on the pages.
> The downside I see is that there may not be anywhere near
> 25000 such discardable pages, so most of this zone would go unused, and
> the memory would be "wasted" as in the case where it is pre-reserved.
> Also, this is not currently supported, so new code would
> have to be designed and implemented.
>
> I would appreciate people's comments about:
>
> 1. Does this type of zone make any sense? It
> would have to co-exist with the current movable zone type.
Ideally can't there be a reserved zone created from which all the
remaining on-the fly zones are shared based on CoW ?
> 2. How hard would it be to implement this? The new zone type would
> need to be supported and "discardable" pages steered into this zone.
>
Most VMs do support ballooning, CoW and other forms of sharing and
can provide as basis for any memory management projects.
> 3. Are there better ways of allocating a large memory region
> with minimal latency that I haven't mentioned here?
>
Hmm...there are mechanisms as pointed by yourself but they all depend
on the policy of consolidation, priority and security of operations.
> Thanks.
>
> Larry Bassel
>
> --
> 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>
>
--
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>
next prev parent reply other threads:[~2011-09-29 6:07 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 [this message]
2011-09-29 16:38 ` [Xen-devel] " Dan Magenheimer
2011-09-29 17:00 ` Larry Bassel
2011-10-05 16:56 ` Larry Bassel
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=CAOFJiu1_HaboUMqtjowA2xKNmGviDE55GUV4OD1vN2hXUf4-kQ@mail.gmail.com \
--to=spniphadkar@gmail.com \
--cc=Xen-devel@lists.xensource.com \
--cc=lbassel@codeaurora.org \
--cc=linux-mm@kvack.org \
--cc=vgandhi@codeaurora.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).