PERFORCE change 119371 for review

[Rui Paulo]

At Wed, 09 May 2007 21:29:25 +0100,
Rui Paulo wrote:
> 
> At Wed, 9 May 2007 15:43:32 -0400,
> John Baldwin wrote:
> > 
> > On Wednesday 09 May 2007 03:33:11 pm Attilio Rao wrote:
> > > 2007/5/9, John Baldwin <jhb at freebsd.org>:
> > > > On Sunday 06 May 2007 05:10:35 pm Rui Paulo wrote:
> > > > > http://perforce.freebsd.org/chv.cgi?CH=119371
> > > > >
> > > > > Change 119371 by rpaulo at rpaulo_epsilon on 2007/05/06 21:10:15
> > > > >
> > > > >       We don't need any scheduler support because:
> > > > >       1) msrtemp is a child of cpu - this implies that every
> > > > >          rdmsr/cpuid instruction will be executed on that CPU.
> > > >
> > > > No, that isn't true.  You do need to use sched_bind() for that so you are
> > > > really on the desired CPU when you read the MSR.
> > > 
> > > I think he just needs msr of the cpu where curthread is executed, so
> > > any scheduler lock should be needed.
> > > If he needs to know msr of a particular CPU he really needs so, but it
> > > doesn't seem the case.
> > 
> > The sysctl is per-CPU, so he needs the msr from a specific CPU in the sysctl 
> > handler.  I.e., it's like dev.cpu.0.temp or some such.
> 
> Yes, I need the MSR from a specific CPU.
> Does sched_pin() solve the problem? Or do I need to use shed_bind()?

Doh, forget this question.