Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 18 Oct 2001 15:58:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 18 Oct 2001 15:57:13 -0400 Received: from perninha.conectiva.com.br ([200.250.58.156]:60171 "HELO perninha.conectiva.com.br") by vger.kernel.org with SMTP id ; Thu, 18 Oct 2001 15:57:05 -0400 Date: Thu, 18 Oct 2001 16:35:43 -0200 (BRST) From: Marcelo Tosatti To: Linus Torvalds Cc: "David S. Miller" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] fork() failing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Oct 2001, Linus Torvalds wrote: > > On Thu, 18 Oct 2001, David S. Miller wrote: > > > > There are also some platforms using 1-order allocations > > for page tables as well. > > > > But I don't know if I agree with this special casing. > > Well, it's not really any _new_ special casing - we've always had the > special case for order-0, the patch just expands it to order-1 too. > > That said, I think a separate flag saying "don't try too hard", which can > be used for all orders, including 0 and 1, and just says that "ok, we want > you to balance things, but if this allocation fails that's not a big > deal". > > So the flag would just always be implicit in allocations of higher orders, > because big orders are basically impossible to guarantee.. Read my last mail on this thread... A single flag saying "we can fail easily" does not sound good to me. Imagine people changing the point where the if ((gfp_mask & __GFP_FAIL)) return; check is done (inside the freeing routines). I would like to have a _defined_ meaning for a "fail easily" allocation, and a simple unique __GFP_FAIL flag can't give us that IMO. - 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/