[lkml]   [2000]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [2*PATCH] alpha I/O access and mb()

    On Sat, 9 Dec 2000, Abramo Bagnara wrote:

    > Gérard Roudier wrote:
    > >
    > >
    > > Based on that, let me claim that most of blind barriers inserted this way
    > > are useless (thus sob-optimal) and may band-aid useful barriers that are
    > > missing. The result is subtle bugs, hidden most of the time, that we will
    > > have to suffer for decades.
    > >
    > > The only way to do things right regarding ordering it to have device
    > > drivers _aware_ of such issues. Now, if we are happy with broken portable
    > > or platform-independant drivers that rely on broken hidden ordering
    > > alchemy rather than on correctness, then it is another story.
    > I see perfectly your point and this is the reason why we have
    > __raw_write[bwlq] in 2.4, but write[bwlq] expected semantic is to ensure
    > that write *happens* and are visible by other agents.

    Ordering and flushing are different issues. Hardware may flush in order to
    guarantee some order, but if nothing is to order it may not. A memory
    barrier does not guarantee you that a write will go faster to the system
    BUS. Basically, if no other agent does need the data and the data is
    cacheable, the flushing is just useless. Confusing ordering and flushing
    is a serious mistake in my humble opinion.

    Speaking about MMIO which is not cacheable, indeed we want the data
    targetting the MMIO area to be flushed quickly. But we also want the
    device to have a consistent vue of the data in memory for all IOs it is
    provided with. Usually, we have to deal with the following:

    1) Prepare some DATA in cachable memory (DMA related)
    2) Ensure ordering: i.e. may insert a MEMORY BARRIER
    3) Tell the device about the IO to perform: write to MMIO

    Drivers that are unaware of (2) _are_ broken.


    1) Read device status register to know about IO that completed.
    2) Ensure ordering of speculative reads against DMA from the device.
    i.e. may insert a MEMORY (READ) BARRIER.
    3) Look into memory for IOs that have completed.

    Drivers that are unaware of (2) _are_ broken.

    Since the hidden BUS stuff just puts its implicit barriers at the wrong
    place regarding the above, any device driver that does DMA and that does
    not use explicit barriers is likely to be broken even if it uses normal
    IOs. Reason is that the PCI specifications also allow host bridges to post
    IO transactions and thus assuming 15 years old ISA-like behaviour is plain

    > You can tell me that almost nobody uses __raw_write now and this is bad
    > and I agree with you, but sometime this is not a perfect world ;-)

    The various BUS abstractions I have to suffer of are indeed a great
    demonstration of our world being not perfect. ;-)

    Hehe... I read so often that most drivers are broken that shoe-horning
    bunches or barriers, bus things and other band-aidings is probably the
    only way to have some of them mostly usable. ;-)
    Or could it be that current O/S guys are still ISA-bussed. ;-)

    By the way, given our real world, your patch is probably quite
    reasonnable. My point was not to disagree with it, in particular.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:51    [W:0.023 / U:400.520 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site