On Tue, 11 Oct 2011 16:23:22 -0400 Satoru Moriya <satoru.moriya@xxxxxxx> wrote: > On 10/11/2011 03:55 PM, Andrew Morton wrote: > > On Tue, 11 Oct 2011 15:32:11 -0400 > > Satoru Moriya <satoru.moriya@xxxxxxx> wrote: > > > >> On 10/10/2011 06:37 PM, Andrew Morton wrote: > >>> On Fri, 7 Oct 2011 20:08:19 -0700 (PDT) David Rientjes > >>> <rientjes@xxxxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>