Subject: Re: Patches for EST and SMP
To: Juraj Hercek <>
From: Juan RP <>
List: current-users
Date: 03/19/2007 20:26:55
On Sunday 18 March 2007, Juraj Hercek wrote:
> Juan RP wrote:
> > On Saturday 17 March 2007, Juan RP wrote:
> >> Hi,
> >>
> >> I'm posting patches for review and test. The patches do:
> >
> > I fixed two things that were wrong right now:
> >
> > * I was increasing atomically the counter in curcpu() two times, before
> >   x86_broadcast_ipi().
> > * After a write with msr_cpu_broadcast_write(), ci->ci_msr_rvalue was not
> >   updated with the new value, so it always had previous value.
> >
> > A NetBSD user tested it for me with Enhanced Speedstep, and I tested it
> > with p4tcc, I can't see any problem and the value is read or written in
> > all CPUs correctly.
> >
> >
> >
> >
> >
> > Are there any problems with this code now?
> > ...
> I've looked at the changes to est.c and seen an #ifdefs for
> multiprocessor support. Wouldn't be possible to hide it behind the
> wrmsr/rdmsr functions? (I don't know if it is/isn't against some policy
> or whatever - I'm still newbie regarding netbsd kernel...).
> I'm writing this because I've a separate patch for est (will post it
> soon) which implements undervolting (the new undervolting version is as
> much as possible detached from original est code and is a sort of layer
> above it), where I have couple of lines with wrmsr/rdmsr  which I need
> to adjust for multiprocessor according to your changes in est.c.
> If it's not viable, It might be useful to have some sort of api to
> detach processor specific things at est level. However, this is probably
> an issue for a separate mailing thread (if it makes sense to deal with
> this at all).

Latest code does not depend in MULTIPROCESSOR anymore, when
we want to write the MSR for UP or SMP we use
msr_cpu_broadcast(&mcb, MSR_CPU_BROADCAST_WRITE) and this one
will know if it's a SMP system, otherwise it will write the value in curcpu().

Thanks for your comments.

Juan RP's blog - NetBSD/pkgsrc news in Spanish