Messages in this thread | | | From | "Manfred Spraul" <> | Subject | Re: Q: explicit alignment control for the slab allocator | Date | Wed, 7 Mar 2001 21:32:45 +0100 |
| |
From: "Jes Sorensen" <jes@linuxcare.com> > >>>>> "Manfred" == Manfred Spraul <manfred@colorfullife.com> writes: > > Manfred> Mark Hemment wrote: > >> As no one uses the feature it could well be broken, but is that a > >> reason to change its meaning? > > Manfred> Some hardware drivers use HW_CACHEALIGN and assume certain > Manfred> byte alignments, and arm needs 1024 byte aligned blocks. > > Isn't that just a reinvention of SMP_CACHE_BYTES? Or are there > actually machines out there where the inbetween CPU cache line size > differs from the between CPU and DMA controller cache line size? > No.
First of all HW_CACHEALIGN aligns to the L1 cache, not SMP_CACHE_BYTES. Additionally you sometimes need a guaranteed alignment for other problems, afaik ARM needs 1024 bytes for some structures due to cpu restrictions, and several usb controllers need 16 byte alignment.
And some callers of kmem_cache_create() want SMP_CACHE_BYTES alignment, other callers (and DaveM) expect L1_CACHE_BYTES alignment.
It's more a API clarification than a real change.
I think it can wait until 2.5: drivers should use pci_alloc_consistent_pool(), not kmalloc_aligned()+virt_to_bus(), arm can wait and the ability to choose between SMP and L1 alignment is not that important.
-- Manfred
- 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/
| |