lkml.org 
[lkml]   [2006]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] MMIO accessors & barriers documentation
    From
    Date

    > Please explain what drivers will need changes because of this. Not just
    > the few you really care about, but _all_ that could be plugged into
    > PowerPC
    > machines' PCI busses, and might need changes because of changing the
    > ordering semantics of readX()/writeX() from the supposed standard Linux
    > semantics (i.e., the x86 semantics).

    They won't. They will still work, and in some (many ?) case better due
    to the removal of a potential bug since lots of driver don't have a
    barrier where they should be with relaxed semantics. So the net effect
    is positive here.

    Now, it also means that we -can- start improving drivers we care about
    to use the relaxed semantics and benefit from there. And since the
    semantics are well defined, all archs with some sort of relaxed ordering
    will be able to benefit in a way or another.

    In addition, it will allow us to get a small optimisation on PowerPC vs.
    the current situation by slightly relaxing wmb() which currently has to
    do a full sync because it might be used to order memory vs. MMIO, which
    it will no longer do (it will go back to a pure memory store barrier).

    Anyway, Paul has a patch we are testing that makes our writel/readl's
    synchronous (by moving the sync to before writel, adding an eieio before
    readl, and doing the percpu trick so spin_unlock magically does a sync
    when a writel occurred). With that, we'll get full correctness with no
    more sync's in writel than we had before. We are running some benchs
    here now to see what kind of performance impact it has overall, and if
    we are happy, that can make it into 2.6.18 and close the problem of
    drivers assuming ordered MMIO vs. memory at least.

    Then, in a -separate- step, we can provide a set of relaxed accessors
    that will allow for additional performance improvements on the hot path
    of selected drivers.

    I'm tired of arguing over and over again the same thing here anyway,
    I'll post a new version of the document including some of the feedback
    we got already and will submit it for inclusion along with a
    __writel/__readl implementation for powerpc (and a generic one that
    defaults to readl/writel) for the 2.6.19 timeframe.

    We'll see from there if there are more constructive comments.

    Ben.



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

    \
     
     \ /
      Last update: 2006-09-13 03:37    [W:0.024 / U:28.888 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site