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
| ||
|
Date: Wed, 18 May 2011 12:21:08 -0500 (CDT) From: Christoph Lameter <cl@...ux.com> To: Pekka Enberg <penberg@...helsinki.fi> cc: David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>, Andrew Morton <akpm@...ux-foundation.org>, James Bottomley <James.Bottomley@...senpartnership.com>, Colin King <colin.king@...onical.com>, Raghavendra D Prabhu <raghu.prabhu13@...il.com>, Jan Kara <jack@...e.cz>, Chris Mason <chris.mason@...cle.com>, Rik van Riel <riel@...hat.com>, Johannes Weiner <hannes@...xchg.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, linux-kernel <linux-kernel@...r.kernel.org>, linux-ext4 <linux-ext4@...r.kernel.org> Subject: Re: [PATCH 2/4] mm: slub: Do not wake kswapd for SLUBs speculative high-order allocations On Wed, 18 May 2011, Pekka Enberg wrote: > On 5/17/11 12:10 AM, David Rientjes wrote: > > On Fri, 13 May 2011, Mel Gorman wrote: > > > > > To avoid locking and per-cpu overhead, SLUB optimisically uses > > > high-order allocations and falls back to lower allocations if they > > > fail. However, by simply trying to allocate, kswapd is woken up to > > > start reclaiming at that order. On a desktop system, two users report > > > that the system is getting locked up with kswapd using large amounts > > > of CPU. Using SLAB instead of SLUB made this problem go away. > > > > > > This patch prevents kswapd being woken up for high-order allocations. > > > Testing indicated that with this patch applied, the system was much > > > harder to hang and even when it did, it eventually recovered. > > > > > > Signed-off-by: Mel Gorman<mgorman@...e.de> > > Acked-by: David Rientjes<rientjes@...gle.com> > > Christoph? I think this patch is sane although the original rationale was to > workaround kswapd problems. I am mostly fine with it. The concerns that I have is if there is a large series of high order allocs then at some point you would want kswapd to be triggered instead of high order allocs constantly failing. Can we have a "trigger once in a while" functionality? -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists