RE: [CFT][RFC] HT scheduler

Nakajima, Jun
2003-12-17T00:39:27Z

> You forgot the one where no HT knowledge can be used for
optimizations.
>
> - Asserting the CPU's #LOCK pin to take control of the system bus.
That in
> MP system translate into the signaling CPU taking full control of
the
> system bus until the pin is deasserted.
>

It is not the case with UP (single socket) using HT, where some
optimization for locks could be available. But you still need locks for
the logical processors.

Jun

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Davide Libenzi
> Sent: Tuesday, December 16, 2003 4:25 PM
> To: Linus Torvalds
> Cc: Jamie Lokier; Nick Piggin; bill davidsen; Linux Kernel Mailing
List
> Subject: Re: [CFT][RFC] HT scheduler
>
> On Tue, 16 Dec 2003, Linus Torvalds wrote:
>
> > I bet it is. In a big way.
> >
> > The lock does two independent things:
> > - it tells the core that it can't just crack up the load and store.
> > - it also tells other memory ops that they can't re-order around
it.
>
> You forgot the one where no HT knowledge can be used for
optimizations.
>
> - Asserting the CPU's #LOCK pin to take control of the system bus.
That in
> MP system translate into the signaling CPU taking full control of
the
> system bus until the pin is deasserted.
>
>
>
> - Davide
>
>
> -
> 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/