[Top] [All Lists]

Re: [patch] linux 2.4.17: An mb() rework

To: "Maciej W. Rozycki" <>
Subject: Re: [patch] linux 2.4.17: An mb() rework
From: Jason Gunthorpe <>
Date: Thu, 31 Jan 2002 23:44:30 -0700 (MST)
In-reply-to: <>
Reply-to: Jason Gunthorpe <>
On Thu, 31 Jan 2002, Maciej W. Rozycki wrote:

>  Hmm, wmb() is pretty clearly defined.  The current implementation does
> not enforce strict ordering and is thus incorrect.  Note that the R4400
> manual explicitly states a cached write can bypass an uncached one, hence
> the CPU may exploit weak ordering under certain circumstances.  The "sync" 
> instruction was specifically defined to avoid such a risk.

Yes, you are correct. I suppose *mb() must also work correctly with the
cache flush macros - didn't think about that one! 

I'm afraid I don't have any manuals for any of the MIPS chips just 3rd
party ones SB1, RM7K and SR71000 - which is why I have some many
odd questions. :>

> > No, a sync will still empty the write buffer. It may halt the pipeline for
> > many (~80 perhaps) cycles while posted write data is dumped to the system
> > controller.
>  Then it's an implementation bug.  For a CPU in the UP mode "sync" is only
> defined to prevent write and read reordering -- there is nothing about
> flushing.

Did some more research + phoning.. RM7K is definately documented to dump
the write buffer on 'sync'. The RM7K guide even has an example (7.8.5)
where it implies that sync also forces a write back of any dirty cache
lines - gah! (Hard to belive though..)

Sandcraft tells me that sync only waits for outstanding reads on their
chips - so it is very cheap. Writebacks from cached and uncached writes
are never put out of program order. 

Sorry my viewpoint is skewed by this small sampling of processors :<

> You need an "mb()", since you are changing the access type, so you need to
> synchronize both kinds.


>  I don't understand what the purpose of the above code is, except that it
> wastes a cycle.  Please elaborate. 

There was a miscommunication on my part, please ignore it.

I hope Ralf accepts your patch, I think it will be good to have.


<Prev in Thread] Current Thread [Next in Thread>