Andrew requested I reply to this email, so it's old, but here it is. On Mon, 9 Dec 2013, Johannes Weiner wrote: > We check for fatal signals during the repeated charge attempts and > reclaim. Should we be checking for PF_EXITING too? > Michal has proposed that patch and I question whether we should be doing that because if significant memory allocation can be done in the exit() path after PF_EXITING either now or in the future, then it does not allow memory to be set aside for system oom handlers given the suggested memcg configuration from Tejun that limits the amount of "user" memory to a top-level memcg limit that can be overcommitted below it and bypasses these charges to root that would disallow the userspace oom handlers from getting memory that they have been reserved. In other words, if a 64GB machine has top-level memcgs "user" with limit of 62GB and "oom" with limit of 2GB for system oom handlers, that 2GB cannot be guaranteed with all of these bypasses (uncharged memory, such as unaccounted kernel memory, memory reserves). > You even re-inforced this motivation by suggesting the separate memcg > margin check right before the OOM kill, so don't blame us for > misunderstanding the exact placement of this check as your main > argument when you repeated it over and over. > We've talked about a lot of stuff in these threads, yes. > All I object to is that the OOM killer is riddled with last-second > checks of whether the OOM situation is still existant. We establish > that the context is OOM and once we are certain we are executing, > period. > This patch moves a check from being "last second" to actually before the oom killer is called at all, you should be pleased. > Not catching PF_EXITING in the long window between the first reclaim > and going OOM is a separate issue and I can see that this should be > fixed but it should be checked before we start invoking OOM. > Doesn't seem like an issue with this patch. -- 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>