Messages in this thread | | | Date | Mon, 10 Oct 2011 15:37:23 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH -v2 -mm] add extra free kbytes tunable |
| |
On Fri, 7 Oct 2011 20:08:19 -0700 (PDT) David Rientjes <rientjes@google.com> 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?
| |