Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762861AbXEXEDR (ORCPT ); Thu, 24 May 2007 00:03:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758974AbXEXEDF (ORCPT ); Thu, 24 May 2007 00:03:05 -0400 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:50906 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1758457AbXEXEDE (ORCPT ); Thu, 24 May 2007 00:03:04 -0400 Date: Wed, 23 May 2007 21:03:02 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Paul Mackerras cc: Russell King , KAMEZAWA Hiroyuki , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, jens.axboe@oracle.com Subject: Re: Define CONFIG_BOUNCE to avoid useless inclusion of bounce buffer logic. In-Reply-To: <18005.2746.374990.29287@cargo.ozlabs.ibm.com> Message-ID: References: <20070522133906.ae9c362a.kamezawa.hiroyu@jp.fujitsu.com> <20070523140702.GA16972@flint.arm.linux.org.uk> <18005.2746.374990.29287@cargo.ozlabs.ibm.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: 1514 Lines: 31 On Thu, 24 May 2007, Paul Mackerras wrote: > That is (presumably) true today, but is in fact a redefinition of what > ZONE_DMA historically was for. I do not know too much about the history but when I tried to correlate all the different ways that arches use the zone this definition was the most consistent between all of them. Add the fact that we always had the MAX_DMA_ADDRESS limit for DMA. I think the history is due to the platform at the time only being able to do DMA to low memory addresses. The definition of ZONE_DMA is rather problematic. The only common denominator is the limitaiton by MAX_DMA_ADDRESS. But that limit varies from platform to platform. Thus the meaning of GFP_DMA is also varying from platfom to platform. > Also there is the problem that some drivers use ZONE_DMA allocations > because their device can only generate addresses below some limit, but > on a platform with an IOMMU there is in fact no restriction on what > memory the device can access. That problem is to some extend addressed by switching ZONE_DMA off which results in GFP_DMA becoming meaningless. And if GFP_DMA and ZONE_DMA is gone from a platform then the MAX_DMA_ADDRESS inconsistencies are solved since the cause of the inconsistencies has evaporated. - 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/