From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [RFC] Initial alpha-0 for new page allocator API From: Alan Cox In-Reply-To: <200609222110.25118.ak@suse.de> References: <200609220817.59801.ak@suse.de> <200609222110.25118.ak@suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 22 Sep 2006 21:10:50 +0100 Message-Id: <1158955850.24572.37.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org Return-Path: To: Andi Kleen Cc: Christoph Lameter , Martin Bligh , akpm@google.com, linux-kernel@vger.kernel.org, Christoph Hellwig , James Bottomley , linux-mm@kvack.org List-ID: Ar Gwe, 2006-09-22 am 21:10 +0200, ysgrifennodd Andi Kleen: > We already have that scheme. Any existing driver should be already converted > away from GFP_DMA towards dma_*/pci_*. dma_* knows all the magic > how to get memory for the various ranges. No need to mess up the > main allocator. Add an isa_device class and that'll fall into place nicely. isa_alloc_* will end up asking for 20bit DMA and it will work nicely. > Anyways, i suppose what could be added as a fallback would be a > really_slow_brute_force_try_to_get_something_in_this_range() allocator Implementation detail although I note that the defrag/antifrag proposal made at the vm summit would mean it mostly come out for free. If we have an isa_dma_* API then the detail is platform specific. > that basically goes through the buddy lists freeing in >O(1) > and does some directed reclaim, but that would likely be a separate > path anyways and not need your new structure to impact the O(1) > allocator. Just search within the candidate 4MB (or whatever it is these days) chunks. > I am still unconvinced of the real need. The only gaping hole was > GFP_DMA32, which we fixed already. Various devices are 30 and 31bit today - some broadcom for example. > Ok there is aacraid with its weird 2GB limit, > Ok now I'm sure someone will come up with a counter example (hi Alan), but: > - Does the device really need more than 16MB? > - How often is it used on systems with >1/2GB with a 64bit kernel? > [consider that 64bit kernels don't support ISA] > - How many users of that particular thing around? Ok the examples I know about are - ESS Maestro series audio - PCI, common on 32bit boxes a few years ago, no longer shipped and unlikely to be met on 64bit. Also slow allocations is fine. - Some aacraid, mostly only for control structures. Those found on 64bit are probably fine with slow alloc. - Broadcom stuff - not sure if 30 or 31bit, around today and on 64bit - Floppy controller > I think my point stands. I think its worthy of discussion. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org