[lkml]   [2012]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module
On Fri, 13 Jan 2012, 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

 \ /
  Last update: 2012-01-13 12:09    [W:0.066 / U:9.712 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site