On Wed, 27 Nov 2013, Johannes Weiner wrote: > The long-standing, user-visible definition of the current line agrees > with me. You can't just redefine this, period. > > I tried to explain to you how insane the motivation for this patch is, > but it does not look like you are reading what I write. But you don't > get to change user-visible behavior just like that anyway, much less > so without a sane reason, so this was a complete waste of time :-( > If you would like to leave this to Andrew's decision, that's fine. Michal has already agreed with my patch and has acked it in -mm. If userspace is going to handle oom conditions, which is possible today and will be extended in the future, then it should only wakeup as a last resort when there is no possibility of future memory freeing. It would be stupid to have userspace wakeup to handle the oom condition and then require it determine if the kernel simply needed to give it access to memory reserves for the allocating task to exit and free memory so it doesn't actually need to do anything. Section 10 of Documentation/cgroups/memory.txt defines the necessary actions for processes waiting on this notification to make forward progress, it doesn't expect a process is already going to exit and free memory on its own. Waking up in such a condition would be absolutely ludicrous. Furthermore, if you're looking for notification simply when the memcg oom limit has been reached, you can use memory thresholds. If you're looking for notification simply when reclaim is suffering severe pressure, you can use VMPRESSURE_CRITICAL. I've been patient in this thread, but at this point I think everything has been said and it's pointless to continue going in circles. Thanks for your time. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>