linux-kernel - Re: [RFC] : mm : / Patch / Suggestion : Add 1 order or agressiveness to wakeup

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] [day] [month] [year] [list]

Message-Id: <1187863478.6114.364.camel@twins>
Date:	Thu, 23 Aug 2007 12:04:38 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Mitchell Erblich <erblichs@...thlink.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"\"Ingo Molnar\"" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [RFC]  : mm : / Patch / Suggestion : Add 1 order or
	agressiveness to wakeup_kswapd() : 1 line / 1 arg change

On Thu, 2007-08-23 at 02:35 -0700, Mitchell Erblich wrote:
> Group,
> 
>     On the infrequent condition of failing to recieve a page from the
>     freelists, one of the things you do is call wakeup_kswapd()(exception of
>     NUMA or GFP_THISNODE).
> 
>     Asuming that wakeup_kswapd() does what we want, this call is
>     such a high overhead call that you want to make sure that the
>     call is infrequent.

It just wakes up a thread, it doesn't actually wait for anything.
So the function is actually rather cheap.

>     My initial guess is that it REALLY needs to re-populate the
>     freelists just before they/it is used up. However, the simple change
>     is being suggested NOW.

kswapd will only stop once it has reached the high watermarks

>     Assuming that on avg that the order value will be used, you should
>     increase the order to cover two allocs of that same level of order,
>     thus the +1. If on the chance that later page_alloc() calls need
>     fewer pages (smaller order) then the extra pages will be available
>     for more page_allocs(). If later calls have larger orders, hopefully
>     the latency between the calls is great enough that other parts of
>     the system will respond to the low memory / on the freelist(s).

by virtue of kswapd only stopping reclaim when it reaches the high
watermark you already have that it will free more than one page (its
started when we're below the low watermark, so it'll free at least
high-min pages).

Changing the order has quite a different impact, esp now that we have
lumpy reclaim.

>     Line 1265 within function __alloc_pages(), mm/page_alloc.c
> 
> wakeup_kswapd(*z, order);
>       to
> wakeup_kswapd(*z, order + 1);
> 
> In addition, isn't a call needed to determine that the
> freelist(s) are almost empty, but are still returning a page?

didn't we just do that by finding out that ALLOC_WMARK_LOW fails to
return a page?


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