lkml.org 
[lkml]   [2010]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert oom rewrite series
On Mon, 15 Nov 2010, Figo.zhang wrote:

> i am doubt that a new rewrite but the athor canot provide some evidence and
> experiment result, why did you do that? what is the prominent change for your
> new algorithm?
>
> as KOSAKI Motohiro said, "you removed CAP_SYS_RESOURCE condition with ZERO
> explanation".
>
> David just said that pls use userspace tunable for protection by
> oom_score_adj. but may i ask question:
>
> 1. what is your innovation for your new algorithm, the old one have the same
> way for user tunable oom_adj.
>

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.

The goal behind oom_score_adj vs. oom_adj was for several reasons, as
pointed out before:

- give it a unit (proportion of available memory), oom_adj had no unit,

- allow it to work on a linear scale for more control over
prioritization, oom_adj had an exponential scale,

- give it a much higher resolution so it can be fine-tuned, it works with
a granularity of 0.1% of memory (~128M on a 128G machine), and

- allow it to describe the oom killing priority of a task regardless of
its cpuset attachment, mempolicy, or memcg, or when their respective
limits change.

> 2. if server like db-server/financial-server have huge import processes (such
> as root/hardware access processes)want to be protection, you let the
> administrator to find out which processes should be protection. you
> will let the financial-server administrator huge crazy!! and lose so many
> money!! ^~^
>

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.

> 3. i see your email in LKML, you just said
> "I have repeatedly said that the oom killer no longer kills KDE when run on my
> desktop in the presence of a memory hogging task that was written specifically
> to oom the machine."
> http://thread.gmane.org/gmane.linux.kernel.mm/48998
>
> so you just test your new oom_killer algorithm on your desktop with KDE, so
> have you provide the detail how you do the test? is it do the
> experiment again for anyone and got the same result as your comment ?
>

Xorg tends to be killed less because of the change to the heuristic's
baseline, which is now based on rss and swap instead of total_vm. This is
seperate from the issues you list above, but is a benefit to the oom
killer that desktop users especially will notice. I, personally, am
interested more in the server market and that's why I looked for a more
robust userspace tunable that would still be applicable when things like
cpusets have a node added or removed.


\
 
 \ /
  Last update: 2010-11-15 11:17    [W:0.101 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site