lkml.org 
[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: new IRQ scalability changes in 2.3.48
> no, they would be bigger because with Linus' suggestion the UP kernel uses
> spinlocks to make the kernel fully preemptible - we will be able to
> reschedule the kernel in a preemptive way at any point that does not hold
> any spinlock (or lock). The SMP kernel would still reschedules in a
> 'cooperative' way, because spinlocks would not have this 'collect total
> current spinlock count' property (and thus preempting kernel space would
> not be allowed).

I guess I am misunderstanding something, or surely someone else would
come
up with this a long time ago:

UP can be changed to reschedule whenever no spinlocks are held, because
there
is a global count of locks held that can be checked cheaply.
SMP don't have such a count, as the count would pingpong from cache to
cache.

But do we need a total count? Seems to me each processor may have a
count how
many locks it holds - independent of other processors. And if *this*
processor
don't hold any locks then it ought to be able to reschedule even if
another processor hold some lock? The new process shceduled may try to
get that lock
and block, but the current process may do that too.

Helge Hafting

-
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.023 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site