Re: [LKML] Re: [PATCH v3] ad7877: keep dma rx buffers in seperatecache lines

[David Woodhouse]

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@xxxxxxxxx                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/