Re: [PATCH] oom: split out forced OOM killer

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

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_.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]