On Wed Jan 18, 2023 at 7:05 PM AEST, David Howells wrote: > 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. Not too bad on modern ppc64. Changing MSR in general has to flush the pipe and even re-fetch, because it can alter memory translation among other things, so it was heavy. Everything we support has a lightweight MSR change that just modifies the interrupt enable bit and only needs minor serialisation (although we still have that software-irq-disable thing which avoids the heavy MSR problem on old CPUs). Thanks, Nick
