On Fri, 24 Feb 2006, Benjamin LaHaise wrote:
> On Fri, Feb 24, 2006 at 10:04:23AM -0500, Alan Stern wrote:
> > What do you think of the two suggestions in my previous message?
>
> Even if the read version of the lock only touches a cacheline local to
> the cpu, you'd still have to use the lock prefix to allow for correctness
> when a writer comes along. It is not cacheline bouncing that worries me,
> it is serialising instructions and memory barriers as those hurt immensely
> when the data is in the cache. I've been looking at a lot of profiles on
> P4s of late, and every single locked instruction is painful as it means
> all of the memory ordering rules come into play. Neither suggestion
> addresses that overhead that has been introduced.
In that case you should be worried not about acquiring and releasing the
rwsem at the beginning and end of blocking_notifier_call_chain; you should
be worried about all the RCU serialization in the core
notifier_call_chain routine.
In fact, that could be changed for blocking notifier chains. Since we own
the readlock, we know that the list won't get changed while we're using
it. So the blocking version of the call-chain routine could avoid using
the RCU dereferencing mechanism.
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.
Alan Stern
-
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]
