lkml.org 
[lkml]   [2015]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] oom: split out forced OOM killer
On 2015-06-08 13:59, David Rientjes wrote:
> On Fri, 5 Jun 2015, Austin S Hemmelgarn wrote:
>
>>> I'm not sure what the benefit of this is, and it's adding more code.
>>> Having multiple pathways and requirements, such as constrained_alloc(), to
>>> oom kill a process isn't any clearer, in my opinion. It also isn't
>>> intended to be optimized since the oom killer called from the page
>>> allocator and from sysrq aren't fastpaths. To me, this seems like only a
>>> source code level change and doesn't make anything more clear but rather
>>> adds more code and obfuscates the entry path.
>>
>> At the very least, it does make the semantics of sysrq-f much nicer for admins
>> (especially the bit where it ignores the panic_on_oom setting, if the admin
>> wants the system to panic, he'll use sysrq-c). There have been times I've had
>> to hit sysrq-f multiple times to get to actually kill anything, and this looks
>> to me like it would eliminate that rather annoying issue as well.
>>
>
> Are you saying there's a functional change with this patch/
>
I believe so (haven't actually read the patch itself, just the
changelog), although it is only a change for certain configurations to a
very specific and (I hope infrequently) used piece of functionality.
Like I said above, if I wanted to crash my system, I'd be using sysrq-c;
and if I'm using sysrq-f, I want _some_ task to die _now_.

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2015-06-08 21:01    [W:0.119 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site