On Fri, Dec 7, 2018 at 4:05 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Fri, Dec 07, 2018 at 02:16:19PM +0800, Nicolas Boichat wrote: > > +#ifdef CONFIG_ZONE_DMA32 > > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA32 > > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA32 > > This name doesn't make any sense. Why not ARM_V7S_TABLE_SLAB_FLAGS ? Sure, will fix in v6 then. > > +#else > > +#define ARM_V7S_TABLE_GFP_DMA GFP_DMA > > +#define ARM_V7S_TABLE_SLAB_CACHE SLAB_CACHE_DMA > > Can you remind me again why it is, on machines which don't support > ZONE_DMA32, why we have to allocate from ZONE_DMA? My understanding > is that 64-bit machines have ZONE_DMA32 and 32-bit machines don't. > So shouldn't this rather be GFP_KERNEL? Sorry I mean to reply on the v4 thread, Christoph raised the same question (https://patchwork.kernel.org/patch/10713025/). I don't know, and I don't have all the hardware needed to test this ,-( Robin and Will both didn't seem sure. I'd rather not introduce a new regression, this patch series tries to fix a known arm64 regression, where we _need_ tables to be in DMA32. If we want to change 32-bit hardware to use GFP_KERNEL, and we're sure it works, that's fine by me, but it should be in another patch set. Hope this makes sense, Thanks, > Actually, maybe we could centralise this in gfp.h: > > #ifdef CONFIG_64BIT > # ifdef CONFIG_ZONE_DMA32 > #define GFP_32BIT GFP_DMA32 > # else > #define GFP_32BIT GFP_DMA > #else /* 32-bit */ > #define GFP_32BIT GFP_KERNEL > #endif >
