Date: Sat, 19 Nov 2005 13:41:14 -0800 (PST)
Message-Id: <20051119.134114.115024780.davem@davemloft.net>
To: wli@holomorphy.com
Cc: hugh@veritas.com, akpm@osdl.org, nickpiggin@yahoo.com.au,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/11] unpaged: unifdefed PageCompound
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <20051119205557.GO6916@holomorphy.com>
References: <20051117.154323.10862063.davem@davemloft.net>
	<Pine.LNX.4.61.0511192003060.2846@goblin.wat.veritas.com>
	<20051119205557.GO6916@holomorphy.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1371
Lines: 30

From: William Lee Irwin III <wli@holomorphy.com>
Date: Sat, 19 Nov 2005 12:55:57 -0800

> On Thu, 17 Nov 2005, David S. Miller wrote:
> >> I think this is a good change regardless of the VM_RESERVED issues.
> >> I've been wanting to use this facility in some sparc64 bits in
> >> the past, for example.  But since it was HUGETLB guarded that
> >> wasn't possible.
> 
> On Sat, Nov 19, 2005 at 08:15:13PM +0000, Hugh Dickins wrote:
> > I've only just found that we have to supply the __GFP_COMP flag to get
> > this working.  And one of the routes through snd_dma_alloc_pages goes
> > to sbus_alloc_consistent.  Would you be happy for me to send Andrew a
> > patch with sparc and sparc64 sbus_alloc_consistent including __GFP_COMP?
> > Ought I to do the same in the sparc and sparc64 pci_alloc_consistent??
> 
> I usually end up deferring to Dave on the driver issues, but this time
> I can independently agree in an informed manner.

What is it needed for in this case?  We never try to use those
pci_alloc_consistent() pages independantly, ie. freeing up
individual pages from a non-zero order allocation.

Just curious. :-)

-
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/