Messages in this thread | | | Subject | Re: [LKML] Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines | From | David Woodhouse <> | Date | Wed, 19 May 2010 13:48:45 +0100 |
| |
On Wed, 2010-05-12 at 13:03 +1000, Nick Piggin wrote: > I don't think it's necessarily a good idea. MINALIGN is an enforced > minimum alignment and the allocator has no leeway in reducing this. > In a UP system, or in a memory constrained system, it might be a better > idea to pack objects more tightly, for example. > > If we allow drivers to assume kmalloc is cacheline aligned, it will be > (practically) impossible to revert this because it would require driver > audits.
No, we definitely don't, and shouldn't, allow drivers to assume that kmalloc is cacheline-aligned.
However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That happens to mean "cacheline-aligned" for cache-incoherent architectures, but drivers should never really have to think about that.
> So whenever strengthening API guarantees like this, it is better to be > very careful and conservative. Probably even introducing a new API with > the stronger semantics (even if it is just a wrapper in the case where > KMALLOC_MINALIGNED *is* cacheline sized).
We're not talking about strengthening API guarantees. It's _always_ been this way; it's just that some architectures are buggy.
But it looks like ARM, PowerPC, SH, MIPS, Microblaze, AVR32 and all unconditionally cache-coherent architectures _do_ get it right already.
> I think adding to the DMA API would be a better idea. If the arch knows > that kmalloc is suitable for the job directly, it can be used. Drivers > can use the new interface, and kmalloc doesn't get saddled with > alignment requirements.
No, that would be a change which would require auditing all drivers. The _current_ rule is that buffers returned from kmalloc() are OK for DMA.
-- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
| |