[lkml]   [2005]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] swapin rlimit

* Andrew Morton <> wrote:

> Ingo Molnar <> wrote:
> >
> > * Andrew Morton <> wrote:
> >
> > > Similarly, that SGI patch which was rejected 6-12 months ago to kill
> > > off processes once they started swapping. We thought that it could be
> > > done from userspace, but we need a way for userspace to detect when a
> > > task is being swapped on a per-task basis.
> >
> > wouldnt the clean solution here be a "swap ulimit"?
> Well it's _a_ solution, but it's terribly specific.
> How hard is it to read /proc/<pid>/nr_swapped_in_pages and if that's
> non-zero, kill <pid>?

on a system with possibly thousands of taks, over /proc, on a
high-performance node where for a 0.5% improvement they are willing to
sacrifice maidens? :)

Seriously, while nr_swapped_in_pages ought to be OK, i think there is a
generic problem with /proc based stats.

System instrumentation people are already complaining about how costly
/proc parsing is. If you have to get some nontrivial stat from all
threads in the system, and if Linux doesnt offer that counter or summary
by default, it gets pretty expensive.

One solution i can think of would be to make a binary representation of
/proc/<pid>/stats readonly-mmap-able. This would add a 4K page to every
task tracked that way, and stats updates would have to update this page
too - but it would make instrumentation of running apps really
unintrusive and scalable.

Another addition would be some mechanism for a monitoring app to capture
events in the PID space: so that they can mmap() new tasks [if they are
interested] on a non-polling basis, i.e. not like readdir on /proc. This
capability probably has to be a system-call though, as /proc seems too
quirky for it. The system does not wait on the monitoring app(s) to
catch up - if it's too slow in reacting and the event buffer overflows
then tough luck - monitoring apps will have no impact on the runtime
characteristics of other tasks. In theory this is somewhat similar to
auditing, but the purpose would be quite different, and it only cares
about PID-space events like 'fork/clone', 'exec' and 'exit'.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-11-04 09:10    [W:0.079 / U:5.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site