Re: [PATCH -v2 -mm] add extra free kbytes tunable

[Andrew Morton]

On Fri, 7 Oct 2011 20:08:19 -0700 (PDT)
David Rientjes <rientjes@xxxxxxxxxx> wrote:

> On Thu, 1 Sep 2011, Rik van Riel wrote:
> 
> > Add a userspace visible knob to tell the VM to keep an extra amount
> > of memory free, by increasing the gap between each zone's min and
> > low watermarks.
> > 
> > This is useful for realtime applications that call system
> > calls and have a bound on the number of allocations that happen
> > in any short time period.  In this application, extra_free_kbytes
> > would be left at an amount equal to or larger than than the
> > maximum number of allocations that happen in any burst.
> > 
> > It may also be useful to reduce the memory use of virtual
> > machines (temporarily?), in a way that does not cause memory
> > fragmentation like ballooning does.
> > 
> 
> I know this was merged into -mm, but I still have to disagree with it 
> because I think it adds yet another userspace knob that will never be 
> obsoleted, will be misinterepted, and is tied very closely to the 
> implementation of page reclaim, both synchronous and asynchronous.

Yup.  We should strenuously avoid merging it, for these reasons.

>  I also 
> think that it will cause regressions on other cpu intensive workloads 
> that don't require this extra freed memory because it works as a global 
> heuristic and is not tied to any specific application.
> 
> I think it would be far better to reclaim beyond above the high watermark 
> if the types of workloads that need this tunable can be somehow detected 
> (the worst case scenario is being a prctl() that does synchronous reclaim 
> above the watermark so admins can identify these workloads), or be able to 
> mark allocations within the kernel as potentially coming in large bursts 
> where allocation is problematic.

The page allocator already tries harder if the caller has
rt_task(current).  Why is this inadequate?  Can we extend this idea
further to fix whatever-the-problem-is?

Does there exist anything like a test case which demonstrates the need
for this feature?

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