From: Paul Jackson <pj@engr.sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: pj@sgi.com, mort@sgi.com, linux-mm@kvack.org, emery@sgi.com,
bron@sgi.com, Simon.Derr@bull.net, linux-kernel@vger.kernel.org
Subject: Re: [Patch] cpusets policy kill no swap
Date: Tue, 22 Mar 2005 15:10:08 -0800 [thread overview]
Message-ID: <20050322151008.4a259486.pj@engr.sgi.com> (raw)
In-Reply-To: <20050319225855.475e4167.akpm@osdl.org>
Thanks Andrew - you're right. Drop this patch in /dev/null.
* I will look around for some way that user code can
detect that a task has provoked swapping, or propose
a small patch, perhaps to /proc, for that, if need be.
* I agree that the action, killing a task or whatever, can
and should be instigated by user level code. The kernel
provides the essential mechanisms; user code decides the
policy, and elaborates the mechanisms.
* I'm concerned that polling some /proc state will either be too
wasteful of cycles (if we poll fast) or have too much delay to
trigger (if we poll slow). Though I need some real numbers,
to see if this is a real problem. It was definitely a problem
in a past life, but that may not apply here. The Linux 2.6
swapper is much more NUMA friendly.
Note, however, that something like rlimit, used to impose
other limits on task resource consumption, depends on specific
kernel hooks to catch the violation (using too much memory,
say) rather than insisting that user space code scan /proc
information looking for violators. The former is just way
too efficient compared to the latter.
* I'm still casting about for appropriate mechanisms (if polling
some /proc data is not adequate) to:
1) enable user space code to control some kernel trigger
that fires when a task causes more swapping than the
setting allows (something like rlimit?), and
2) an economical mechanism for the kernel to deliver such
events back to user space (call_usermodehelper or
satisfying a read on a special file?).
If you, or any lurker, has further thoughts, they would be
welcome.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
--
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>
prev parent reply other threads:[~2005-03-22 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-20 1:48 Paul Jackson
2005-03-20 6:58 ` Andrew Morton
2005-03-20 7:09 ` Paul Jackson
2005-03-22 23:10 ` Paul Jackson [this message]
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=20050322151008.4a259486.pj@engr.sgi.com \
--to=pj@engr.sgi.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=bron@sgi.com \
--cc=emery@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mort@sgi.com \
--cc=pj@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