Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > And for the kernel, where we don't have bad locking, and where we > actually use fine-grained locks that are _near_ the data that we are > locking (the lockref of the dcache is obviously one example of that, > but the skbuff queue you mention is almost certainly exactly the same > situation): the lock is right by the data that the lock protects, and > the "shared lock cacheline" model simply does not work. You'll bounce > the data, and most likely you'll also touch the same lock cacheline > too. Yeah. The reason I was actually wondering about them was if it would be possible to avoid the requirement to disable interrupts/softirqs to, say, modify the skbuff queue. On some arches actually disabling irqs is quite a heavy operation (I think this is/was true on ppc64, for example; it certainly was on frv) and it was necessary to "emulate" the disablement. David
