Subject: Re: scheduler woes on MPACPI kernel
To: Thor Lancelot Simon <>
From: Daniel Carosone <>
List: current-users
Date: 01/19/2005 16:51:51
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 19, 2005 at 12:17:39AM -0500, Thor Lancelot Simon wrote:
> For *some* workloads, notably certain application-level
> floating-point-intensive workloads, even when there's already an out of
> order execution engine working on the same problems, hyperthreading can
> be a small win.

Nevertheless, the approach has promise, even if the present chips and
implementations don't show it.  For example, it may be that in some
future rev of the chip, there's room for an extra floating point and a
couple of integer units, or something. These go into the common pool
of execution resources. Where it might normally be very hard to make
use of them from a single instruction stream, it might be easier from
two. =20

It's a cheaper compromise than duplicating the whole rest of the cpu
for a true multi-core die, and possibly more effective if some of the
duplicated resources then sit idle again.

> But for most workloads, it is not.=20

It seems pretty borderline, either way, at least until you get to
multi-xeon machines where you start tripping over scheduler

My entirely unscientific observation is that it seems to help most
when part of the workload involves reasonable levels of I/O; it seems
that interrupts can be serviced by one 'cpu' while computationally
intensive work can continue in the other.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.0 (NetBSD)