[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20101123160020.7B99.A69D9226@jp.fujitsu.com>
Date: Tue, 23 Nov 2010 16:16:57 +0900 (JST)
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: kosaki.motohiro@...fujitsu.com,
David Rientjes <rientjes@...gle.com>,
"Figo.zhang" <zhangtianfei@...dcoretech.com>,
"Figo.zhang" <figo1802@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...l.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] Revert oom rewrite series
sorry for the delay.
> > 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.
>
> > 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 ?
It's insufficient.
a63d83f427fbce97a6cea0db2e64b0eb8435cd10 (oom: badness heuristic rewrite)
introduced a lot of incompatibility to oom_adj and oom_score.
Theresore I would sugestted full revert and resubmit some patches which
cherry pick no pain piece.
--
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