Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264262AbUFXLRB (ORCPT ); Thu, 24 Jun 2004 07:17:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264270AbUFXLRB (ORCPT ); Thu, 24 Jun 2004 07:17:01 -0400 Received: from cantor.suse.de ([195.135.220.2]:56732 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264262AbUFXLQt (ORCPT ); Thu, 24 Jun 2004 07:16:49 -0400 Date: Thu, 24 Jun 2004 13:13:47 +0200 Message-ID: From: Takashi Iwai To: Andi Kleen Cc: Terence Ripperda , discuss@x86-64.org, linux-kernel@vger.kernel.org, andrea@suse.de Subject: Re: 32-bit dma allocations on 64-bit platforms In-Reply-To: <20040623234644.GC38425@colin2.muc.de> References: <20040623213643.GB32456@hygelac> <20040623234644.GC38425@colin2.muc.de> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1526 Lines: 34 At 24 Jun 2004 01:46:44 +0200, Andi Kleen wrote: > > > > I must say I'm somewhat reluctant to break an working in tree driver. > > > Especially for the sake of an out of tree binary driver. Arguably the > > > problem is probably not limited to you, but it's quite possible that > > > even the in tree DRI drivers have it, so it would be still worth to > > > fix it. > > > > agreed. I completely understand that there is no desire to modify the > > core kernel to help our driver. that's one of the reasons I looked through > > the other drivers, as I suspect that this is a problem for many drivers. I > > only looked through the code for each briefly, but didn't see anything to > > handle this. I suspect it's more of a case that the drivers have not been > > stress tested on an x86_64 machine w/ 4+ G of memory. > > We usually handle it using the swiotlb, which works. > > pci_alloc_consistent is limited to 16MB, but so far nobody has really > complained about that. If that should be a real issue we can make > it allocate from the swiotlb pool, which is usually 64MB (and can > be made bigger at boot time) Can't it be called with GFP_KERNEL at first, then with GFP_DMA if the allocated pages are out of dma mask, just like in pci-gart.c? (with ifdef x86-64) Takashi - 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/