RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

[<leonid.moiseichuk@nokia.com>]

> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@google.com]
> Sent: 12 January, 2012 21:55
> To: Moiseichuk Leonid (Nokia-MP/Helsinki)
....
> 
> 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.
If you have another product with big difference in memory size, applications etc. you might need to re-calibrate reactions.
Let's focus on realistic cases.

> 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.

That is not possible - signals usually set at level you have 20-50 MB to react. 
Slowdown is natural thing if you have lack of space for code paging, I do not see any ways to fix it.

>  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.

It is not necessary.

> 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.

Define "lowmem situation" first.  For proposed approach it is from 50-90% of memory usage until user-space can do something.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>