Messages in this thread |  | | Date | Mon, 08 Jun 2015 14:58:46 -0400 | From | Austin S Hemmelgarn <> | Subject | Re: [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] |  |