Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762869AbXISRiz (ORCPT ); Wed, 19 Sep 2007 13:38:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763005AbXISRgd (ORCPT ); Wed, 19 Sep 2007 13:36:33 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:52315 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1763002AbXISRgc (ORCPT ); Wed, 19 Sep 2007 13:36:32 -0400 Date: Wed, 19 Sep 2007 10:36:31 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Andi Kleen cc: Christoph Hellwig , Mel Gorman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [00/17] [RFC] Virtual Compound Page Support In-Reply-To: Message-ID: References: <20070919033605.785839297@sgi.com> 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 Content-Length: 1423 Lines: 29 On Wed, 19 Sep 2007, Andi Kleen wrote: > > alloc_page(GFP_VFALLBACK, order, ....) > > Is there a reason this needs to be a GFP flag versus a wrapper > around alloc_page/free_page ? page_alloc.c is already too complicated > and it's better to keep new features separated. The only drawback > would be that free_pages would need a different call, but that > doesn't seem like a big problem. I tried to make this a wrapper but there is a lot of logic in __alloc_pages() that would have to be replicated. Also there are specific places in __alloc_pages() were we can establish that we have enough memory but its the memory fragmentation that prevents us from satisfying the request for a larger page. > I'm also a little dubious about your attempts to do vmalloc in > interrupt context. Is that really needed? GFP_ATOMIC allocations of > large areas seem to be extremly unreliable to me and not design. Even > if it works sometimes free probably wouldn't work there due to the > flushes, which is very nasty. It would be better to drop that. The flushes are only done on virtuall mapped architectures (xtensa) and are simple ASM code that can run in an interrupt context - 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/