lkml.org 
[lkml]   [2010]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [LKML] Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines
    On Wed, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote:
    > 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.

    Good.


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

    DMA-safe for GFP_DMA, or all kmalloc?

    Either way, yes the arch should take care of those details.


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

    It just appeared, in the post I replied to, that there was a suggestion
    of making it explicitly cacheline aligned. If I misread that, ignore
    me.

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


    \
     
     \ /
      Last update: 2010-05-19 15:09    [W:5.866 / U:0.596 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site