From: "Jes Sorensen" <[EMAIL PROTECTED]>
> >>>>> "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
