lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 07 Dec 2006 12:30:53 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	linux-kernel@...r.kernel.org
Subject: additional oom-killer tuneable worth submitting?


The kernel currently has a way to adjust the oom-killer score via 
/proc/<pid>/oomadj.

However, to adjust this effectively requires knowledge of the scores of 
all the other processes on the system.

I'd like to float an idea (which we've implemented and been using for 
some time) where the semantics are slightly different:

We add a new "oom_thresh" member to the task struct.
We introduce a new proc entry "/proc/<pid>/oomthresh" to control it.

The "oom-thresh" value maps to the max expected memory consumption for 
that process.  As long as a process uses less memory than the specified 
threshold, then it is immune to the oom-killer.

On an embedded platform this allows the designer to engineer the system 
and protect critical apps based on their expected memory consumption. 
If one of those apps goes crazy and starts chewing additional memory 
then it becomes vulnerable to the oom killer while the other apps remain 
protected.

If a patch for the above feature was submitted, would there be any 
chance of getting it included?  Maybe controlled by a config option?

Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ