To: =?iso-8859-1?q?Lo=EFc_Greni=E9?= <loic.grenie@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: vmalloc_32 and SLAB incompatible in 2.6.23.9
References: <9b06e8d20801230114v1e09e5e8s6a4b438562c62619@mail.gmail.com>
From: Andi Kleen <andi@firstfloor.org>
Date: 23 Jan 2008 10:35:28 +0100
In-Reply-To: <9b06e8d20801230114v1e09e5e8s6a4b438562c62619@mail.gmail.com>
Message-ID: <p73wsq0lw9r.fsf@crumb.suse.de>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1207
Lines: 23

"Lo?c Greni?" <loic.grenie@gmail.com> writes:

>      Since GFP_DMA32 is not considered a valid flag, vmalloc_32 and
>   SLAB are incompatible in kernel 2.6.23.9 (and probably later ones).
>   It might be as simple as adding GFP_DMA32 everywhere where
>   GFP_DMA is used in mm/slab.c, but I don't dare do it. I personally
>   switched to SLUB.

I don't think it would really work for slub either.

If you look at /proc/slabinfo you see that there are separate DMA
caches. That is because sl[abo]b all cache objects and if the 
objects have different requirements (like GFP_DMA, GFP_DMA32, GFP_KERNEL)
they would need different caches. Otherwise you risk getting
later objects originally allocated with the wrong flags.

To make GFP_DMA32 work would require adding another set of DMA32
caches to all kmalloc caches etc or a separate one for each
custom kmem cache that you use that only gets _DMA32 objects.

Better just use __get_free_pages() directly. 

-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/