On Sat, Nov 18, 2006 at 09:46:24PM +0300, Oleg Nesterov wrote:
> On 11/17, Paul E. McKenney wrote:
> >
> > Oleg, any thoughts about Jens's optimization? He would code something
> > like:
> >
> > if (srcu_readers_active(&my_srcu))
> > synchronize_srcu();
> > else
> > smp_mb();
>
> Well, this is clearly racy, no? I am not sure, but may be we can do
>
> smp_mb();
> if (srcu_readers_active(&my_srcu))
> synchronize_srcu();
>
> in this case we also need to add 'smp_mb()' into srcu_read_lock() after
> 'atomic_inc(&sp->hardluckref)'.
>
> > However, he is doing ordered I/O requests rather than protecting data
> > structures.
>
> Probably this makes a difference, but I don't understand this.
OK, one hypothesis here...
The I/Os must be somehow explicitly ordered to qualify
for I/O-barrier separation. If two independent processes
issue I/Os concurrently with a third process doing an
I/O barrier, the I/O barrier is free to separate the
two concurrent I/Os or not, on its whim.
Jens, is the above correct? If so, what would the two processes
need to do in order to ensure that their I/O was considered to be
ordered with respect to the I/O barrier? Here are some possibilities:
1. I/O barriers apply only to preceding and following I/Os from
the process issuing the I/O barrier.
2. As for #1 above, but restricted to task rather than process.
3. I/O system calls that have completed are ordered by the
barrier to precede I/O system calls that have not yet
started, but I/O system calls still in flight could legally
land on either side of the concurrently executing I/O
barrier.
4. Something else entirely?
Given some restriction like one of the above, it is entirely possible
that we don't even need the memory barrier...
Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
