Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756150Ab2K0WET (ORCPT ); Tue, 27 Nov 2012 17:04:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29217 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754525Ab2K0WES (ORCPT ); Tue, 27 Nov 2012 17:04:18 -0500 Message-ID: <50B5387C.1030005@redhat.com> Date: Tue, 27 Nov 2012 17:02:36 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Johannes Weiner CC: Linus Torvalds , Andrew Morton , Mel Gorman , George Spelvin , Johannes Hirte , Tomas Racek , Jan Kara , Dave Hansen , Josh Boyer , Valdis Kletnieks , Jiri Slaby , Thorsten Leemhuis , Zdenek Kabelac , Bruno Wolff III , linux-mm , Linux Kernel Mailing List Subject: Re: kswapd craziness in 3.7 References: <1354049315-12874-1-git-send-email-hannes@cmpxchg.org> <50B52DC4.5000109@redhat.com> <20121127214928.GA20253@cmpxchg.org> In-Reply-To: <20121127214928.GA20253@cmpxchg.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2223 Lines: 53 On 11/27/2012 04:49 PM, Johannes Weiner wrote: > On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote: >> On 11/27/2012 03:58 PM, Linus Torvalds wrote: >>> Note that in the meantime, I've also applied (through Andrew) the >>> patch that reverts commit c654345924f7 (see commit 82b212f40059 >>> 'Revert "mm: remove __GFP_NO_KSWAPD"'). >>> >>> I wonder if that revert may be bogus, and a result of this same issue. >>> Maybe that revert should be reverted, and replaced with your patch? >>> >>> Mel? Zdenek? What's the status here? >> >> Mel posted several patches to fix the kswapd issue. This one is >> slightly more risky than the outright revert, but probably preferred >> from a performance point of view: >> >> https://lkml.org/lkml/2012/11/12/151 >> >> It works by skipping the kswapd wakeup for THP allocations, only >> if compaction is deferred or contended. > > Just to clarify, this would be a replacement strictly for the > __GFP_NO_KSWAPD removal revert, to control how often kswapd is woken > up for higher order allocations like THP. > > My patch is to fix how kswapd actually does higher order reclaim, and > it is required either way. > > [ But isn't the _reason_ why the "wake up kswapd more carefully for > THP" patch was written kind of moot now since it was developed > against a crazy kswapd? It would certainly need to be re-evaluated. > My (limited) testing didn't show any issues anymore with waking > kswapd unconditionally once it's fixed. ] Kswapd going crazy is certainly a large part of the problem. However, that leaves the issue of page_alloc.c waking up kswapd when the system is not actually low on memory. Instead, kswapd is woken up because memory compaction failed, potentially even due to lock contention during compaction! Ideally the allocation code would only wake up kswapd if memory needs to be freed, or in order for kswapd to do memory compaction (so the allocator does not have to). -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/