Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759873AbYCHApb (ORCPT ); Fri, 7 Mar 2008 19:45:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755461AbYCHApU (ORCPT ); Fri, 7 Mar 2008 19:45:20 -0500 Received: from one.firstfloor.org ([213.235.205.2]:54418 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754333AbYCHApT (ORCPT ); Fri, 7 Mar 2008 19:45:19 -0500 Date: Sat, 8 Mar 2008 01:46:54 +0100 From: Andi Kleen To: "Luiz Fernando N. Capitulino" Cc: Andi Kleen , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] [0/13] General DMA zone rework Message-ID: <20080308004654.GQ7365@one.firstfloor.org> References: <200803071007.493903088@firstfloor.org> <20080307175148.3a49d8d3@mandriva.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080307175148.3a49d8d3@mandriva.com.br> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3139 Lines: 87 On Fri, Mar 07, 2008 at 05:51:48PM -0300, Luiz Fernando N. Capitulino wrote: > Em Fri, 7 Mar 2008 10:07:10 +0100 (CET) > Andi Kleen escreveu: > > | I chose to implement a new "maskable memory" allocator to solve these > | problems. The existing page buddy allocator is not really suited for > | this because the data structures don't allow cheap allocation by physical > | address boundary. > > These patches are supposed to work, I think? Yes they work fine here and survived quite some stress testing. But of course I only have limited configurations. > > I've tried to give them a try but got some problems. First, the > simple test case seems to fail miserably: Hmm I guess you got a pretty filled up 16MB area already. Do you have a full log? It just couldn't allocate some memory for the 24bit mask, but that is likely because it just ran out of memory. I suppose it will work if you cut down the allocations in the test case a bit, e.g. decrease NUMALLOC to 10 and perhaps MAX_LEN to 5*PAGE_SIZE. Did that in my copy. > > """ > testing mask alloc upto 24 bits > gpm1 3 mask 3fffff size 20440 total 62KB failed > gpm1 4 mask 3fffff size 24369 total 62KB failed > gpm1 6 mask 3fffff size 15255 total 64KB failed > gpm1 7 mask 3fffff size 12676 total 64KB failed > gpm1 8 mask 3fffff size 23917 total 64KB failed > gpm1 9 mask 3fffff size 11682 total 64KB failed > gpm1 10 mask 3fffff size 23091 total 64KB failed > gpm1 11 mask 3fffff size 16880 total 64KB failed > gpm1 12 mask 3fffff size 17257 total 64KB failed > gpm1 13 mask 3fffff size 8686 total 64KB failed > gpm1 14 mask 3fffff size 9871 total 64KB failed > gpm1 15 mask 3fffff size 19740 total 64KB failed > gpm1 16 mask 3fffff size 11557 total 64KB failed > gpm1 18 mask 3fffff size 23723 total 67KB failed > gpm1 19 mask 3fffff size 16136 total 67KB failed > gpm2 6 mask 3fffff size 4471 failed > gpm2 7 mask 3fffff size 16868 failed > gpm2 8 mask 3fffff size 22093 failed > gpm2 9 mask 3fffff size 17666 failed > gpm2 11 mask 3fffff size 14416 failed > gpm2 12 mask 3fffff size 10825 failed > gpm2 13 mask 3fffff size 3918 failed > gpm2 14 mask 3fffff size 6255 failed > gpm2 15 mask 3fffff size 2428 failed > gpm2 16 mask 3fffff size 517 failed > gpm2 18 mask 3fffff size 12890 failed > gpm2 19 mask 3fffff size 3211 failed > verify & free > mask fffff > mask 1fffff > mask 3fffff > mask 7fffff > mask ffffff > done > """ > > Then boot up goes on and while init is running I get this: Ah, I see the problem. Your sound driver allocates a dma area < 16 bytes. I had added a BUG_ON for that to catch some mistakes (of passing order instead of size), but it triggers here incorrectly. Didn't see that in my testing. I put up an updated patchkit on ftp://firstfloor.org/pub/ak/mask/patches/ It also has some other fixes. Can you retest with that please? Thanks for testing. -Andi -- 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/