From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754134Ab2AYPTo (ORCPT ); Wed, 25 Jan 2012 10:19:44 -0500 Received: from gir.skynet.ie ([193.1.99.77]:41853 "EHLO gir.skynet.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752396Ab2AYPTn (ORCPT ); Wed, 25 Jan 2012 10:19:43 -0500 Date: Wed, 25 Jan 2012 15:19:40 +0000 From: Mel Gorman To: Rik van Riel Cc: linux-mm@kvack.org, lkml , Andrea Arcangeli , Johannes Weiner , Andrew Morton , Minchan Kim , KOSAKI Motohiro Subject: Re: [PATCH v2 -mm 2/3] mm: kswapd carefully call compaction Message-ID: <20120125151940.GC3901@csn.ul.ie> References: <20120124131822.4dc03524@annuminas.surriel.com> <20120124132243.56ce423e@annuminas.surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20120124132243.56ce423e@annuminas.surriel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 24, 2012 at 01:22:43PM -0500, Rik van Riel wrote: > With CONFIG_COMPACTION enabled, kswapd does not try to free > contiguous free pages, even when it is woken for a higher order > request. > > This could be bad for eg. jumbo frame network allocations, which > are done from interrupt context and cannot compact memory themselves. > Higher than before allocation failure rates in the network receive > path have been observed in kernels with compaction enabled. > > Teach kswapd to defragment the memory zones in a node, but only > if required and compaction is not deferred in a zone. > We used to do something vaguely like this in the past and it was reverted because compaction was stalling for too long. With the merging of sync-light, this should be less of an issue but we should be watchful of high CPU usage from kswapd with too much time spent in memory compaction even though I recognise that compaction takes places in kswapds exit path. In 3.3-rc1, there is a risk of high CPU usage anyway because kswapd may be scanning over large numbers of dirty pages it is no longer writing so care will be needed to disguish between different high CPU usage problems. That said, I didn't spot any obvious problems so; Acked-by: Mel Gorman Thanks. -- Mel Gorman SUSE Labs