From: Dave Hansen <haveblue@us.ibm.com>
To: Paul Jackson <pj@engr.sgi.com>
Cc: Mel Gorman <mel@csn.ul.ie>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 0/2 Buddy allocator with placement policy (Version 9) + prezeroing (Version 4)
Date: Thu, 10 Mar 2005 10:16:53 -0800 [thread overview]
Message-ID: <1110478613.16432.36.camel@localhost> (raw)
In-Reply-To: <20050310092201.37bae9ba.pj@engr.sgi.com>
On Thu, 2005-03-10 at 09:22 -0800, Paul Jackson wrote:
> In particular, I am working on preparing a patch proposal for a policy
> that would kill a task rather than invoke the swapper. In
> mm/page_alloc.c __alloc_pages(), if one gets down to the point of being
> about to kick the swapper, if this policy is enabled (and you're not
> in_interrupt() and don't have flag PF_MEMALLOC set), then ask
> oom_kill_task() to shoot us instead. For some big HPC jobs that are
> carefully sized to fit on the allowed memory nodes, swapping is a fate
> worse than death.
>
> The natural place (for me, anyway) to hang such policies is off the
> cpuset.
>
> I am hopeful that cpusets will soon hit Linus's tree.
>
> Would it make sense to specify these buddy allocator fallback policies
> per cpuset as well?
That seems reasonable, but I don't think there necessarily be enough
cpuset users to make this reasonable as the only interface.
Seems like something VMA-based along the lines of madvise() or the NUMA
binding API would be more appropriate. Perhaps default policies
inherited from a cpuset, but overridden by other APIs would be a good
compromise.
I have the feeling that applications will want to give the same kind of
notifications for swapping as they would for memory hotplug operations
as well. In decreasing order of pickiness:
1. Don't touch me at all
2. It's OK to migrate these pages elsewhere on this node
3. It's OK to migrate these pages anywhere
4. It's OK to swap these pages out
Although the node part, at least, can almost certainly be done in
combination with the NUMA api.
-- Dave
--
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/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-03-10 18:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-07 19:39 Mel Gorman
2005-03-07 23:59 ` Dave Hansen
2005-03-10 14:31 ` Mel Gorman
2005-03-10 17:22 ` Paul Jackson
2005-03-10 18:16 ` Dave Hansen [this message]
2005-03-10 20:11 ` Paul Jackson
2005-03-10 20:17 ` Dave Hansen
2005-03-10 20:54 ` Paul Jackson
2005-03-14 14:10 ` Mel Gorman
2005-03-14 19:10 ` Paul Jackson
2005-03-10 17:37 ` Dave Hansen
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=1110478613.16432.36.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=pj@engr.sgi.com \
/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