> -----Original Message----- > From: ext David Rientjes [mailto:rientjes@xxxxxxxxxx] > Sent: 11 January, 2012 22:45 > I think you're misunderstanding the proposal; in the case of a global oom > (that means without memcg) then, by definition, all threads that are > allocating memory would be frozen and incur the delay at the point they > would currently call into the oom killer. If your userspace is alive, i.e. the > application responsible for managing oom killing, then it can wait on > eventfd(2), wake up, and then send SIGTERM and SIGKILL to the appropriate > threads based on priority. > > So, again, why wouldn't this work for you? As I wrote the proposed change is not safety belt but looking ahead radar. If it detects that we are close to wall it starts to alarm and alarm volume is proportional to distance. In close-to-OOM situations device becomes very slow, which is not good for user. The performance difference depends on code size and storage performance to trash code pages but even 20% is noticeable. Practically 2x-5x times slowdown was observed. We can do some actions ahead of time and try to prevent OOM at all like shrink caches in applications, close unused apps etc. If OOM still happened due to 3rd party components or misbehaving software even default OOM killer works good enough if oom_score_adj values are properly set. Thus, controlling device on wider set of memory situations looks for me more beneficial than trying to recover when situation is bad. And increasing complexity of recovery mechanism (OOM, Android OOM, OOM with delay), involving user-space into decision-making, makes recovery _potentially_ less predictable. Best Wishes, Leonid -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href