lkml.org 
[lkml]   [2004]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [CFT][RFC] HT scheduler
Date
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
load.

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 <davidsen@tmr.com>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.124 / U:4.088 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site