On Thu, 12 Jan 2012, leonid.moiseichuk@xxxxxxxxx wrote: > 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. > Then it's fundamentally flawed since there's no guarantee that coming with 100MB of the min watermark, for example, means that an oom is imminent and will just result in unnecessary notification to userspace that will cause some action to be taken that may not be necessary. If the setting of these thresholds depends on some pattern that is guaranteed to be along the path to oom for a certain workload, then that will also change depending on VM implementation changes, kernel versions, other applications, etc., and simply is unmaintainable. > 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. > It would be much better to address the slowdown when running out of memory rather than requiring userspace to react and unnecessarily send signals to threads that may or may not have the ability to respond because they may already be oom themselves. You can do crazy things to reduce latency in lowmem memory allocations like changing gfp_allowed_mask to be GFP_ATOMIC so that direct reclaim is never called, for example, and then use the proposed oom killer delay to handle the situation at the time of oom. Regardless, you should be addressing the slowness in lowmem situations rather than implementing notifiers to userspace to handle the events itself, so nack on this proposal. -- 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>