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

[David Rientjes]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/