lkml.org 
[lkml]   [1999]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectCache incoherencies (WAS: New resources - pls, explain :-( )
    On Sun, Aug 22, 1999, Philip Blundell <Philip.Blundell@pobox.com> wrote:

    >>Philip> This is what the dma_cache_xxx functions defined in asm/io.h
    >>Philip> are for.
    >>
    >>Just notice that there is currently no cross-architecture definition
    >>of these macros - all architectures name the differently and the ones
    >>that are coherent don't have them at all.
    >
    >Oh, I thought all the ports had these macros these days (even though most of
    >them are defined to do nothing). Oops.

    And I don't think those macros are enough. I may be wrong, but I beleive
    the way tulip.c is currently fixed for non cache coherent archs is wrong.
    Why ? Because we should also take care of the cache line granularity,
    especially when flushing/invalidating the ring descriptors themselves.

    A ring descriptor is usually smaller than a cache line. That means that
    flushing one of them (after setting the OWN bit for example, or after
    changing the buffer pointer) will also flush whatever datas are next to
    this descriptor (just before or just after). That means that you have the
    possibility of killing datas that are just beeing written by the chip
    into this other descriptor.

    Hopefully I think this doesn't happen on StrongARM since there seem to be
    a notion of half cache line (2 dirty bits per line), and so the half line
    size is just the size of a ring descriptor entry. I'm not sure about the
    exact behaviour of those half-lines, so the potential bug may still be here.

    Another issue, which doesn't seem to be handled in tulip.c neither, is
    that for datas written by the chipset to memory, the cache must be
    invalidated before the chip begins writing (so when the buffers are added
    to the ring), not when the datas are read by the CPU. This is because you
    may still have stale dirty cache lines corresponding to this piece of
    memory that can be flushed at any time, corrupting the datas beeing
    written by the chip.

    The only way I see to make the fist issue safe is to have the ring
    descriptor entries non cachable. Non-cache coherent archs should probably
    define a kmalloc flag to allocate non cachable space. (I still don't know
    what is the cleanest way to get non-cachable space. ioremap ?).

    For the buffers themselves, we should use the inval routine when adding
    skbuffs to the ring, (and make sure skbuffs are cache-aligned, and their
    size a multiple of a cache line too).

    In order to make something compilable on both coherent and incoherent
    archs, we should standardize the #define for the cache line size, add a
    routine/macro to query about the coherency of the bus, and provide a
    "magic" bit for kmalloc that gives you non cachable space.


    --
    Perso. e-mail: <mailto:bh40@calva.net>
    Work e-mail: <mailto:benh@mipsys.com>
    BenH. Web : <http://calvaweb.calvacom.fr/bh40/>




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

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:8.569 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site