On Fri, 13 Jan 2012, leonid.moiseichuk@xxxxxxxxx wrote: > > 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. > > Why? That is expected that product tested and tuned properly, > applications fixed, and at least no apps installed which might consume > 100 MB in second or two. I'm trying to make this easy for you, if you haven't noticed. Your memory threshold, as proposed, will have values that are tied directly to the implementation of the VM in the kernel when its under memory pressure and that implementation evolves at a constant rate. What I'm proposing is limiting the amount of latency that the VM incurs when under memory pressure, notify userspace, and allow it to react to the situation until the delay expires. This doesn't require recalibration for other products or upgraded kernels, it just works all the time. > Slowdown is natural thing if you have lack of space for code paging, I > do not see any ways to fix it. > mlock() the memory that your userspace monitoring needs to send signals to applications, whether those signals are handled to free memory internally or its SIGTERM or SIGKILL. -- 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>