linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

      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