From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 0/14] Avoid overflowing of stack during page reclaim V3 Date: Fri, 2 Jul 2010 12:33:15 -0700 Message-ID: <20100702123315.667c6eac.akpm@linux-foundation.org> References: <1277811288-5195-1-git-send-email-mel@csn.ul.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Chris Mason , Nick Piggin , Rik van Riel , Johannes Weiner , Christoph Hellwig , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Andrea Arcangeli To: Mel Gorman Return-path: In-Reply-To: <1277811288-5195-1-git-send-email-mel@csn.ul.ie> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 29 Jun 2010 12:34:34 +0100 Mel Gorman wrote: > Here is V3 that depends again on flusher threads to do writeback in > direct reclaim rather than stack switching which is not something I'm > likely to get done before xfs/btrfs are ignoring writeback in mainline > (phd sucking up time). IMO, implemetning stack switching for this is not a good idea. We _already_ have a way of doing stack-switching. It's called "schedule()". The only reason I can see for implementing an in-place stack switch would be if schedule() is too expensive. And if we were to see excessive context-switch overheads in this code path (and we won't) then we should get in there and try to reduce the contect switch rate first. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org