lkml.org 
[lkml]   [1999]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.2.2: 2 thumbs up from lm

On Thu, 25 Feb 1999, Richard Gooch wrote:

> I wasn't thinking in terms of long run queues, actually. Well, not
> hugely long like dozens of tasks. Even a with a few tasks, thread
> switching is measurably worse due to aliasing. [...]

the PII L1 cache is 16K and is 4-ways associative. This means the first
time we have a _chance_ to get cachelines kicked out is with 5 running
threads. There is no way you can place 4 task_structs to be misaligned.
And chances are almost zero to get a collision in the 512K+ L2 cache.

> I don't see your point about penalising the "common, few threads"
> case, though. To me it looks like it improves performance
> *always*. Where is the performance hit?

the (obvious i think) cost is in the indirection of the 'outsourced'
runqueue (well, scheduling) part of task_struct. Think of it this way: you
are basically doing the CPU's job, you are slightly fixing up the cache
architecture via introducing one more indirection (and quite some added
complexity).

-- mingo


-
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:50    [W:0.067 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site