linux-kernel - RE: [RFC][PATCH] mm: cut down __GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 May 2011 20:27:43 -0400
From:	Satoru Moriya <satoru.moriya@....com>
To:	Wu Fengguang <fengguang.wu@...el.com>,
	Minchan Kim <minchan.kim@...il.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@...ux.vnet.ibm.com>,
	Dave Young <hidave.darkstar@...il.com>,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux.com>,
	Dave Chinner <david@...morbit.com>,
	David Rientjes <rientjes@...gle.com>
Subject: RE: [RFC][PATCH] mm: cut down __GFP_NORETRY page allocation failures

Hi Wu,
 
> On Mon, May 02, 2011 at 09:29:58PM +0800, Wu Fengguang wrote:
> > > > +                     if (preferred_zone &&
> > > > +                         zone_watermark_ok_safe(preferred_zone, sc->order,
> > > > +                                     high_wmark_pages(preferred_zone),
> > > > +                                     zone_idx(preferred_zone), 0))
> > > > +                             goto out;
> > > > +             }
> > >
> > > As I said, I think direct reclaim path sould be fast if possbile and
> > > it should not a function of min_free_kbytes.
> >
> > It can be made not a function of min_free_kbytes by simply changing
> > high_wmark_pages() to low_wmark_pages() in the above chunk, since
> > direct reclaim is triggered when ALLOC_WMARK_LOW cannot be satisfied,
> > ie. it just dropped below low_wmark_pages().
> >
> > But still, it costs 62ms reclaim latency (base kernel is 29ms).
> 
> I got new findings: the CPU schedule delays are much larger than
> reclaim delays. It does make the "direct reclaim until low watermark
> OK" latency less a problem :)
> 
> 1000 dd test case:
>                 RECLAIM delay   CPU delay       nr_alloc_fail   CAL (last CPU)
> base kernel     29ms            244ms           14586           218440
> patched         62ms            215ms           5004            325

Hmm, in your system, the latency of direct reclaim may be a less problem.

But, generally speaking, in a latency sensitive system in enterprise area
there are two kind of processes. One is latency sensitive -(A) the other
is not-latency sensitive -(B). And usually we set cpu affinity for both processes
to avoid scheduling issue in (A). In this situation, CPU delay tends to be lower
than the above and a less problem but reclaim delay is more critical. 

Regards,
Satoru

> 
> Thanks,
> Fengguang
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/