Subject: Re: [BUG] slab debug vs. L1 alignement
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
In-Reply-To: <3F3D558D.5050803@colorfullife.com>
References: <3F3D558D.5050803@colorfullife.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1060990883.581.87.camel@gaston>
Mime-Version: 1.0
Date: 16 Aug 2003 01:41:24 +0200
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1404
Lines: 34

On Fri, 2003-08-15 at 23:50, Manfred Spraul wrote:
> Ben wrote:
> 
> >Currently, when enabling slab debugging, we lose the property of
> >having the objects aligned on a cache line size.
> >  
> >
> Correct. Cache line alignment is advisory. Slab debugging is not the 
> only case that violates the alignment, for example 32-byte allocations 
> are not padded to the 128 byte cache line size of the Pentium 4 cpus. I 
> really doubt we want that.

Yes, I understand that, but that is wrong for GFP_DMA imho. Also, 
SLAB_MUST_HWCACHE_ALIGN just disables redzoning, which is not smart,
I'd rather allocate more and keep both redzoning and cache alignement,
that would help catch some of those subtle problems when a chip DMA
engine plays funny tricks

> Have you looked at pci_pool_{create,alloc,free,destroy}? The functions 
> were specifically written to provide aligned buffers for DMA operations. 
> Perhaps SCSI should use them?

Of course it should, but it doesn't yet. And other drivers haven't been
ported yet neither though that is slowly happening. Still, I think the
point that a GFP_DMA should be cache aligned still stands, don't you
think ?

Ben.

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