Messages in this thread | | | Date | Mon, 13 Mar 2000 19:56:53 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Mon, 13 Mar 2000, Linus Torvalds wrote:
[agreed about the UP case]
> NOTE NOTE NOTE! You must NOT change the SMP case at all, including the > "are we in the kernel" test. Not only do we not have a global > spinlock_count (and we don't want one - it would be cache-line death), > but even if we used the above heuristic it would be seriously wrong on > SMP, because it would mean that anything that caches the value of > "current CPU" would need to lock. Which is just too expensive to even > think about, because it happens all over the place. On UP, that just > isn't a problem ;)
oops, i missed that indeed, darn. Hm., there are not all that many such places though, and the value itself is cached in current->processor anyway (and 'current' can be cached across reschedules). I cannot see any easy way to avoid this bug in any 'automatic' way though. How can we prevent writing a 'semi-constant' to a local variable, possibly at compile-time?
The impact seems to be moderate i believe: out of 1150 driver-modules only 5 use smp_processor_id() directly. I've checked all these places and none of them is unsafe (smp_processor_id() is never saved to the stack). I've also checked the networking code which uses smp_processor_id() in some places, and only a small amount of code would break: netif_rx saves it to a local variable and while it's mostly called from IRQ contexts, it can be called from syscall level as well. Most other places use smp_processor_id() under some spinlock. But yes, these would be subtle bugs if unfixed.
> There probably are numerous nasty small details that would crop up, but > I'd give it a 15% chance of just working on the first try. > > Oh, and it's not going to be really really efficient. It's going to > increment and decrement global_spinlock_count a lot more than strictly > necessary, but any "clever" approach is just going to be too painful to > think about, and would make the UP locking too different from the SMP > case.
hm, current->spinlock_depth should work pretty well i believe, no? That one is SMP-safe as well. It doesnt have any global cacheline problems either.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |