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
| ||
|
Date: Fri, 11 Jun 2010 08:34:21 +0800 From: Ryan Wang <openspace.wang@...il.com> To: rientjes@...gle.com, mulyadi.santosa@...il.com Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, kernelnewbies@...linux.org Subject: Re: oom killer and long-waiting processes 2010/6/11 David Rientjes <rientjes@...gle.com>: > On Thu, 10 Jun 2010, Ryan Wang wrote: > >> Hi all, >> >> I have one question about oom killer: >> If many processes dealing with network communications, >> but due to bad network traffic, the processes have to wait >> for a very long time. And meanwhile they may consume >> some memeory separately for computation. The number >> of such processes may be large. >> >> I wonder whether oom killer will kill these processes >> when the system is under high pressure? >> > > The kernel can deal with "high pressure" quite well, but in some cases > such as when all of your RAM or your memory controller is filled with > anonymous memory and cannot be reclaimed, the oom killer may be called to > kill "something". It prefers to kill something that will free a large > amount of memory to avoid having to subsequently kill additional tasks > when it kills something small first. > > If there are tasks that you'd either like to protect from the oom killer > or always prefer in oom conditions, you can influence its decision-making > from userspace by tuning /proc/<pid>/oom_adj of the task in question. > Users typically set an oom_adj value of "-17" to completely disable oom > killing of pid (the kernel will even panic if it can't find anything > killable as a result of this!), a value of "-16" to prefer that pid gets > killed last, and a value of "15" to always prefer pid gets killed first. > > Lowering a /proc/<pid>/oom_adj value for a pid from its current value (it > inherits its value from the parent, which is usually 0) is only allowed by > root, more specifically, it may only be done by the CAP_SYS_RESOURCE > capability. > > You can refer to Documentation/filesystems/proc.txt for information on > oom_adj. > Thanks all! -- 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