[lkml]   [2004]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [CFT][RFC] HT scheduler
Rusty Russell wrote:

> Actually, having produced the patch, I've changed my mind.
> While it was spiritually rewarding to separate "struct runqueue" into
> the stuff which was to do with the runqueue, and the stuff which was
> per-cpu but there because it was convenient, I'm not sure the churn is
> worthwhile since we will want the rest of your stuff anyway.
> It (and lots of other things) might become worthwhile if single
> processors with HT become the de-facto standard. For these, lots of
> our assumptions about CONFIG_SMP, such as the desirability of per-cpu
> data, become bogus.

Now that Intel is shipping inexpensive CPUs with HT and faster memory
bus, I think that's the direction of the mass market. It would be very
desirable to have HT help rather than hinder. However, I admit I'm
willing to take the 1-2% penalty on light load to get the bonus on heavy

If someone has measured the effect of HT on interrupt latency or server
transaction response I haven't seen it, but based on a server I just
built using WBEL and the RHEL scheduler, first numbers look as if the
response is better. This is just based on notably less data in the
incoming sockets, but it's encouraging.

"netstat -t | sort +1nr" shows a LOT fewer sockets with unread bytes.

bill davidsen <>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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