From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 9 May 2001 13:36:18 -0300 (BRT) From: Marcelo Tosatti Subject: Re: [PATCH] allocation looping + kswapd CPU cycles In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Mark Hemment Cc: "David S. Miller" , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Wed, 9 May 2001, Mark Hemment wrote: > > On Tue, 8 May 2001, David S. Miller wrote: > > Actually, the change was made because it is illogical to try only > > once on multi-order pages. Especially because we depend upon order > > 1 pages so much (every task struct allocated). We depend upon them > > even more so on sparc64 (certain kinds of page tables need to be > > allocated as 1 order pages). > > > > The old code failed _far_ too easily, it was unacceptable. > > > > Why put some strange limit in there? Whatever number you pick > > is arbitrary, and I can probably piece together an allocation > > state where the choosen limit is too small. > > Agreed, but some allocations of non-zero orders can fall back to other > schemes (such as an emergency buffer, or using vmalloc for a temp > buffer) and don't want to be trapped in __alloc_pages() for too long. > > Could introduce another allocation flag (__GFP_FAIL?) which is or'ed > with a __GFP_WAIT to limit the looping? __GFP_FAIL is in the -ac tree already and it is being used by the bounce buffer allocation code. -- 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.eu.org/Linux-MM/