| 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
| ||
|
Message-ID: <20061208145605.1a8b0815@localhost.localdomain> Date: Fri, 8 Dec 2006 14:56:05 +0000 From: Alan <alan@...rguk.ukuu.org.uk> To: Al Boldi <a1426z@...ab.com> Cc: linux-kernel@...r.kernel.org Subject: Re: additional oom-killer tuneable worth submitting? On Fri, 8 Dec 2006 16:58:29 +0300 Al Boldi <a1426z@...ab.com> wrote: > > That is why we have no-overcommit support. > > Alan, I think you know that this isn't really true, due to shared-libs. Shared libraries are correctly handled by no-overcommit and in fact they have almost zero impact on out of memory questions because the shared parts of the library are file backed and constant. That means they don't actually cost swap space. > > Now there is an argument for > > a meaningful rlimit-as to go with it, and together I think they do what > > you really need. > > The problem with rlimit is that it works per process. Tuning this by hand > may be awkward and/or wasteful. What we need is to rlimit on a global > basis, by calculating an upperlimit dynamically, such as to avoid > overcommit/OOM. You've just described the existing no overcommit functionality, although you've forgotten to allow for pre-reserving of stacks and some other detail that has been found to make it work better as it has been refined. Alan - 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