On Fri, Feb 24, 2006 at 12:59:18PM -0500, Alan Stern wrote:
> It does on architectures where smp_read_barrier_depends() expands into
> something nontrivial. Maybe that doesn't include any of the machines
> you're interested in.
Which includes all of about 1, I think -- alpha. In other words, it's
free.
> > > The atomic chains are a different matter. The ones that don't run in NMI
> > > context could use an rw-spinlock for protection, allowing them also to
> > > avoid memory barriers while going through the list. The notifier chains
> > > that do run in NMI don't have this luxury. Fortunately I don't think
> > > there are very many of them.
> >
> > A read lock is a memory barrier. That's why I'm opposed to using non-rcu
> > style locking for them.
>
> But RCU-style locking can't be used in situations where the reader may
> block. So it's not possible to use it with blocking notifier chains.
Then we shouldn't have non-atomic notifier chains in performance critical
codepaths. The original implementation's hooks into critical paths held
these characteristics. If that property has been broken, please fix it
instead of adding more locking.
-ben
--
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here
and they've asked us to stop the party." Don't Email: <[email protected]>.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
