lkml.org 
[lkml]   [2000]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.200 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site