From: David Rientjes <rientjes@google.com> To: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: "Figo.zhang" <zhangtianfei@leadcoretech.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "Figo.zhang" <figo1802@gmail.com>, lkml <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] Revert oom rewrite series Date: Mon, 15 Nov 2010 12:54:56 -0800 (PST) [thread overview] Message-ID: <alpine.DEB.2.00.1011151243460.8167@chino.kir.corp.google.com> (raw) In-Reply-To: <20101115105735.0f9c1a22@lxorguk.ukuu.org.uk> On Mon, 15 Nov 2010, Alan Cox wrote: > > The goal was to make the oom killer heuristic as predictable as possible > > and to kill the most memory-hogging task to avoid having to recall it and > > needlessly kill several tasks. > > Meta question - why is that a good thing. In a desktop environment it's > frequently wrong, in a server environment it is often wrong. We had this > before where people spend months fiddling with the vm and make it work > slightly differently and it suits their workload, then other workloads go > downhill. Then the cycle repeats. > Most of the arbitrary heuristics were removed from oom_badness(), things like nice level, runtime, CAP_SYS_RESOURCE, etc., so that we only consider the rss and swap usage of each application in comparison to each other when deciding which task to kill. We give root tasks a 3% bonus since they tend to be more important to the productivity or uptime of the machine, which did exist -- albeit with a more dramatic impact -- in the old heursitic. You'll find that the new heuristic always kills the task consuming the most amount of rss unless influenced by userspace via the tunables (or within 3% of root tasks). We always want to kill the most memory-hogging task because it avoids needlessly killing additional tasks when we must immediately recall the oom killer because we continue to allocate memory. If that task happens to be of vital importance to userspace, then the user has full control over tuning the oom killer priorities in such circumstances. > > You have full control over disabling a task from being considered with > > oom_score_adj just like you did with oom_adj. Since oom_adj is > > deprecated for two years, you can even use the old interface until then. > > Which changeset added it to the Documentation directory as deprecated ? > 51b1bd2a was the actual change that deprecated it, which was a direct follow-up to a63d83f4 which actually obsoleted it.
WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com> To: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: "Figo.zhang" <zhangtianfei@leadcoretech.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "Figo.zhang" <figo1802@gmail.com>, lkml <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [PATCH] Revert oom rewrite series Date: Mon, 15 Nov 2010 12:54:56 -0800 (PST) [thread overview] Message-ID: <alpine.DEB.2.00.1011151243460.8167@chino.kir.corp.google.com> (raw) In-Reply-To: <20101115105735.0f9c1a22@lxorguk.ukuu.org.uk> On Mon, 15 Nov 2010, Alan Cox wrote: > > The goal was to make the oom killer heuristic as predictable as possible > > and to kill the most memory-hogging task to avoid having to recall it and > > needlessly kill several tasks. > > Meta question - why is that a good thing. In a desktop environment it's > frequently wrong, in a server environment it is often wrong. We had this > before where people spend months fiddling with the vm and make it work > slightly differently and it suits their workload, then other workloads go > downhill. Then the cycle repeats. > Most of the arbitrary heuristics were removed from oom_badness(), things like nice level, runtime, CAP_SYS_RESOURCE, etc., so that we only consider the rss and swap usage of each application in comparison to each other when deciding which task to kill. We give root tasks a 3% bonus since they tend to be more important to the productivity or uptime of the machine, which did exist -- albeit with a more dramatic impact -- in the old heursitic. You'll find that the new heuristic always kills the task consuming the most amount of rss unless influenced by userspace via the tunables (or within 3% of root tasks). We always want to kill the most memory-hogging task because it avoids needlessly killing additional tasks when we must immediately recall the oom killer because we continue to allocate memory. If that task happens to be of vital importance to userspace, then the user has full control over tuning the oom killer priorities in such circumstances. > > You have full control over disabling a task from being considered with > > oom_score_adj just like you did with oom_adj. Since oom_adj is > > deprecated for two years, you can even use the old interface until then. > > Which changeset added it to the Documentation directory as deprecated ? > 51b1bd2a was the actual change that deprecated it, which was a direct follow-up to a63d83f4 which actually obsoleted it. -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-15 20:55 UTC|newest] Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-11-02 1:43 [PATCH]oom-kill: direct hardware access processes should get bonus Figo.zhang 2010-11-02 1:43 ` Figo.zhang 2010-11-02 3:10 ` David Rientjes 2010-11-02 3:10 ` David Rientjes 2010-11-02 14:24 ` Figo.zhang 2010-11-02 14:24 ` Figo.zhang 2010-11-02 19:34 ` David Rientjes 2010-11-02 19:34 ` David Rientjes 2010-11-03 23:43 ` [PATCH v2]oom-kill: CAP_SYS_RESOURCE " Figo.zhang 2010-11-03 23:43 ` Figo.zhang 2010-11-03 23:47 ` David Rientjes 2010-11-03 23:47 ` David Rientjes [not found] ` <AANLkTimjfmLzr_9+Sf4gk0xGkFjffQ1VcCnwmCXA88R8@mail.gmail.com> 2010-11-04 1:38 ` Figo.zhang 2010-11-04 1:38 ` Figo.zhang 2010-11-04 1:50 ` David Rientjes 2010-11-04 1:50 ` David Rientjes 2010-11-04 2:12 ` Figo.zhang 2010-11-04 2:12 ` Figo.zhang 2010-11-04 2:54 ` David Rientjes 2010-11-04 2:54 ` David Rientjes 2010-11-04 4:42 ` Figo.zhang 2010-11-04 4:42 ` Figo.zhang 2010-11-04 5:08 ` David Rientjes 2010-11-04 5:08 ` David Rientjes 2010-11-09 11:01 ` [PATCH " KOSAKI Motohiro 2010-11-09 11:01 ` KOSAKI Motohiro 2010-11-09 12:24 ` Alan Cox 2010-11-09 12:24 ` Alan Cox 2010-11-09 21:06 ` David Rientjes 2010-11-09 21:06 ` David Rientjes 2010-11-09 21:25 ` David Rientjes 2010-11-09 21:25 ` David Rientjes 2010-11-10 14:38 ` Figo.zhang 2010-11-10 14:38 ` Figo.zhang 2010-11-10 20:50 ` David Rientjes 2010-11-10 20:50 ` David Rientjes 2010-11-09 10:41 ` [PATCH]oom-kill: direct hardware access processes " KOSAKI Motohiro 2010-11-09 10:41 ` KOSAKI Motohiro 2010-11-09 12:24 ` [PATCH v2]mm/oom-kill: " Figo.zhang 2010-11-09 12:24 ` Figo.zhang 2010-11-09 21:16 ` David Rientjes 2010-11-09 21:16 ` David Rientjes 2010-11-10 14:48 ` Figo.zhang 2010-11-10 14:48 ` Figo.zhang 2010-11-14 5:07 ` KOSAKI Motohiro 2010-11-14 5:07 ` KOSAKI Motohiro 2010-11-14 21:29 ` David Rientjes 2010-11-14 21:29 ` David Rientjes 2010-11-15 1:24 ` KOSAKI Motohiro 2010-11-15 1:24 ` KOSAKI Motohiro 2010-11-15 10:03 ` David Rientjes 2010-11-15 10:03 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-28 1:36 ` David Rientjes 2010-11-28 1:36 ` David Rientjes 2010-11-30 13:00 ` KOSAKI Motohiro 2010-11-30 13:00 ` KOSAKI Motohiro 2010-11-30 20:05 ` David Rientjes 2010-11-30 20:05 ` David Rientjes 2010-11-10 15:14 ` [PATCH v3]mm/oom-kill: " Figo.zhang 2010-11-10 15:14 ` Figo.zhang 2010-11-10 15:24 ` Figo.zhang 2010-11-10 15:24 ` Figo.zhang 2010-11-10 21:00 ` David Rientjes 2010-11-10 21:00 ` David Rientjes 2010-11-14 5:21 ` KOSAKI Motohiro 2010-11-14 5:21 ` KOSAKI Motohiro 2010-11-14 21:33 ` David Rientjes 2010-11-14 21:33 ` David Rientjes 2010-11-15 3:26 ` [PATCH] Revert oom rewrite series Figo.zhang 2010-11-15 3:26 ` Figo.zhang 2010-11-15 10:14 ` David Rientjes 2010-11-15 10:14 ` David Rientjes 2010-11-15 10:57 ` Alan Cox 2010-11-15 10:57 ` Alan Cox 2010-11-15 20:54 ` David Rientjes [this message] 2010-11-15 20:54 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 7:16 ` KOSAKI Motohiro 2011-01-04 7:51 ` [PATCH v3]mm/oom-kill: direct hardware access processes should get bonus Figo.zhang 2011-01-04 7:51 ` Figo.zhang 2011-01-04 8:28 ` KAMEZAWA Hiroyuki 2011-01-04 8:28 ` KAMEZAWA Hiroyuki 2011-01-04 8:56 ` Figo.zhang 2011-01-04 8:56 ` Figo.zhang 2011-01-06 0:55 ` KAMEZAWA Hiroyuki 2011-01-06 0:55 ` KAMEZAWA Hiroyuki 2011-01-05 3:32 ` David Rientjes 2011-01-05 3:32 ` David Rientjes 2010-11-14 5:07 [PATCH] Revert oom rewrite series KOSAKI Motohiro 2010-11-14 19:32 ` Linus Torvalds 2010-11-15 0:54 ` KOSAKI Motohiro 2010-11-15 2:19 ` Andrew Morton [not found] ` <AANLkTik_SDaiu2eQsJ9+4ywLR5K5V1Od-hwop6gwas3F@mail.gmail.com> 2010-11-15 4:41 ` Figo.zhang 2010-11-15 4:41 ` Figo.zhang 2010-11-15 6:57 ` KOSAKI Motohiro 2010-11-15 10:34 ` David Rientjes 2010-11-15 23:31 ` Jesper Juhl 2010-11-16 0:06 ` David Rientjes 2010-11-16 10:04 ` Martin Knoblauch 2010-11-16 10:33 ` Alessandro Suardi 2010-11-16 0:13 ` Valdis.Kletnieks 2010-11-16 6:43 ` David Rientjes 2010-11-16 11:03 ` Alan Cox 2010-11-16 13:03 ` Florian Mickler 2010-11-16 14:55 ` Alan Cox 2010-11-16 20:57 ` David Rientjes 2010-11-16 21:01 ` Fabio Comolli 2010-11-17 4:04 ` Valdis.Kletnieks 2010-11-16 15:15 ` Alejandro Riveira Fernández 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-28 1:45 ` David Rientjes 2010-11-30 13:04 ` KOSAKI Motohiro 2010-11-30 20:02 ` David Rientjes 2010-11-23 7:16 ` KOSAKI Motohiro 2010-11-23 23:51 ` KOSAKI Motohiro 2010-11-14 21:58 ` David Rientjes 2010-11-15 23:33 ` Bodo Eggert 2010-11-15 23:50 ` David Rientjes 2010-11-17 0:06 ` Bodo Eggert 2010-11-17 0:25 ` David Rientjes 2010-11-17 0:48 ` Mandeep Singh Baines
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=alpine.DEB.2.00.1011151243460.8167@chino.kir.corp.google.com \ --to=rientjes@google.com \ --cc=akpm@osdl.org \ --cc=alan@lxorguk.ukuu.org.uk \ --cc=figo1802@gmail.com \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=torvalds@linux-foundation.org \ --cc=zhangtianfei@leadcoretech.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.