[Top] [All Lists]

Re: [patch] linux 2.4.17: The second mb() rework (final)

To: Hartvig Ekner <>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <>
Date: Fri, 15 Feb 2002 14:03:45 +0100 (MET)
Cc: Dominic Sweetman <>, "Kevin D. Kissell" <>, Atsushi Nemoto <>,,,,
In-reply-to: <>
Organization: Technical University of Gdansk
On Fri, 15 Feb 2002, Hartvig Ekner wrote:

> But in-order for the CPU is not enough - it also needs to make sure all
> written data is visible for DMA accesses to memory from the outside, which
> is why the writebuffer needs to be flushed by a SYNC as well. From the
> definition of "SYNC":
>       "A store is completed when the stored value is visible to every other
>       processor in the system". 
> Which presumably also includes DMA I/O devices...

 The description found in the R4k manual seems to contradict.  A "sync" on
a single CPU only assures transactions on it's external bus will happen in
order wrt the "sync".  In a multiple-CPU environment all CPUs interested
in a barrier need to execute a "sync".  That's seems natural -- how would 
you define a synchronization point for a CPU that does not execute a

 Since I/O devices have no means to signal a CPU a "sync" operation, how
can you expect a "sync" on the CPU to complete all preceding writes to the
device?  It's only a following read that may imply it.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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