Messages in this thread | | | Date | Tue, 11 Oct 2011 13:54:45 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH -v2 -mm] add extra free kbytes tunable |
| |
On Tue, 11 Oct 2011 16:23:22 -0400 Satoru Moriya <satoru.moriya@hds.com> wrote:
> On 10/11/2011 03:55 PM, Andrew Morton wrote: > > On Tue, 11 Oct 2011 15:32:11 -0400 > > Satoru Moriya <satoru.moriya@hds.com> wrote: > > > >> On 10/10/2011 06:37 PM, Andrew Morton wrote: > >>> 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: > >> > >> Actually page allocator decreases min watermark to 3/4 * min > >> watermark for rt-task. But in our case some applications create a lot > >> of processes and if all of them are rt-task, the amount of watermark > >> bonus(1/4 * min watermark) is not enough. > >> > >> If we can tune the amount of bonus, it may be fine. But that is > >> almost all same as extra free kbytes. > > > > This situation is detectable at runtime. If realtime tasks are being > > stalled in the page allocator then start to increase the free-page > > reserves. A little control system. > > Detecting at runtime is too late for some latency critical systems. > At that system, we must avoid a stall before it happens.
It's pretty darn obvious that the kernel can easily see the situation developing before it happens. By comparing a few integers.
Look, please don't go bending over backwards like this to defend a bad patch. It's a bad patch! It would be better not to have to merge it. Let's do something better.
> Also, if we increase the free-page reserves a.k.a min_free_kbytes, > the possibility of direct reclaim on other workloads increases. > I think it's a bad side effect.
extra_free_kbytes has the same side-effect.
| |