Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264635AbUFXSjE (ORCPT ); Thu, 24 Jun 2004 14:39:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264409AbUFXSjD (ORCPT ); Thu, 24 Jun 2004 14:39:03 -0400 Received: from cantor.suse.de ([195.135.220.2]:54221 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264640AbUFXSdG (ORCPT ); Thu, 24 Jun 2004 14:33:06 -0400 Date: Thu, 24 Jun 2004 20:33:02 +0200 Message-ID: From: Takashi Iwai To: Andrea Arcangeli Cc: Andi Kleen , ak@muc.de, tripperda@nvidia.com, discuss@x86-64.org, linux-kernel@vger.kernel.org Subject: Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms In-Reply-To: <20040624171620.GN30687@dualathlon.random> References: <20040623213643.GB32456@hygelac> <20040623234644.GC38425@colin2.muc.de> <20040624112900.GE16727@wotan.suse.de> <20040624164258.1a1beea3.ak@suse.de> <20040624152946.GK30687@dualathlon.random> <20040624171620.GN30687@dualathlon.random> 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: 3506 Lines: 82 At Thu, 24 Jun 2004 19:16:20 +0200, Andrea Arcangeli wrote: > > On Thu, Jun 24, 2004 at 06:04:58PM +0200, Takashi Iwai wrote: > > At Thu, 24 Jun 2004 17:29:46 +0200, > > Andrea Arcangeli wrote: > > > > > > On Thu, Jun 24, 2004 at 04:58:24PM +0200, Takashi Iwai wrote: > > > > At Thu, 24 Jun 2004 16:42:58 +0200, > > > > Andi Kleen wrote: > > > > > > > > > > On Thu, 24 Jun 2004 16:36:47 +0200 > > > > > Takashi Iwai wrote: > > > > > > > > > > > At Thu, 24 Jun 2004 13:29:00 +0200, > > > > > > Andi Kleen wrote: > > > > > > > > > > > > > > > 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) > > > > > > > > > > > > > > That won't work reliable enough in extreme cases. > > > > > > > > > > > > Well, it's not perfect, but it'd be far better than GFP_DMA only :) > > > > > > > > > > The only description for this patch I can think of is "russian roulette" > > > > > > > > Even if we have a bigger DMA zone, it's no guarantee that the obtained > > > > page is precisely in the given mask. We can unlikely define zones > > > > fine enough for all different 24, 28, 29, 30 and 31bit DMA masks. > > > > > > > > > > > > My patch for i386 works well in most cases, because such a device is > > > > usually equipped on older machines with less memory than DMA mask. > > > > > > > > Without the patch, the allocation is always <16MB, may fail even small > > > > number of pages. > > > > > > why does it fail? note that with the lower_zone_reserve_ratio algorithm I > > > added to 2.4 all dma zone will be reserved for __GFP_DMA allocations so > > > you should have troubles only with 2.6, 2.4 should work fine. > > > So with latest 2.4 it has to fail only if you already allocated 16M with > > > pci_alloc_consistent which sounds unlikely. > > > > If a driver needs large contiguous (e.g. a coule of MB) pages and the > > memory is fragmented, it may still fail. But it's anyway very > > rare... > > Yes. This is why I suggested to use GFP_KERNEL _after_ GFP_DMA has > failed, not the other way around. As Andi said in big systems you're > pretty much guaranteed that GFP_KERNEL will always fail. Ok. > > However, 16MB isn't enough in some cases indeed. For example, the > > following devices are often problematic: > > > > - SB Live (emu10k1) > > This needs many single pages for WaveTable synthesis per user's > > request (up to 128MB). It sets 31bit DMA mask (sigh...) > > then it may never work. If the lowmem below 4G is all allocated in > anonymous memory and you've no swap, there's no way, absolutely no way > to make the above work. I start to think you should fail insmod if the > machine has more than 2^31 bytes of ram being used by the kernel. > > All we can do is to give it a chance to work, that is to call GFP_KERNEL > _after_ GFP_DMA has failed, but again there's no guarantee that it will > work, even if you've only a few gigs of ram. Sure, in extreme cases, it can't work. But at least, it _may_ work better than using only GFP_DMA. And indeed it should (still) work on most of consumer PC boxes. The addition of another zone would help much better, though. 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/