cvs commit: src/sys/i386/i386 local_apic.c src/sys/amd64/amd64 local_apic.c

John Baldwin jhb at freebsd.org
Tue Sep 5 11:49:14 PDT 2006


On Tuesday 05 September 2006 14:18, Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Tuesday 05 September 2006 13:15, Maxim Sobolev wrote:
> >> sobomax     2006-09-05 17:15:25 UTC
> >>
> >>   FreeBSD src repository
> >>
> >>   Modified files:
> >>     sys/i386/i386        local_apic.c 
> >>     sys/amd64/amd64      local_apic.c 
> >>   Log:
> >>   The FreeBSD by default "disables" hyper-threading cores, by not 
scheduling
> >>   any threads to them. However, it still counts those cores as "active 
but
> >>   permanently idle" when calculating system-wide CPUs statistics. It is
> >>   incorrect, since it skews statistics quite a bit and creates real 
problems
> >>   for certain types of applications (monitoring applications for 
example),
> >>   by making them believe that the system does have enough idle CPU 
> > resources,
> >>   while in fact it does not.
> >>   
> >>   Correct the problem by not calling performance counting routines 
> > on "disabled"
> >>   cores. The cleaner solution would be to just disable APIC timer 
interrupts 
> > on
> >>   those cores completely, but ENOTIME here and it is not clear if the
> >>   additional complexity really worth minor performance gain.
> > 
> > Is this going to break various places dividing stats by hw.ncpu (in 
userland) 
> > or mp_ncpus (in kernel)?
> 
> Well, I don't think so, since all those statistics tells is how many 
> times system is found in particular state (idle, system, userland, 
> interrupt),  it doesn't tell how exactly those states are distributed 
> across available CPUs, so that dividing it by number of CPUs doesn't 
> change the whole picture - you can only say that each CPU say is loaded 
> by XX% when the whole system is loaded by XX%. Therefore, I can't 
> imagine any situation when this change would create a problem.

I actually have a patch to make cp_time[] per-cpu which at least clears up the 
confusion for that case.

> >  (That is, are there any such places.   If so, you
> > just broke them.)
> 
> No, I believe that I did not, unless you can provide example of the 
> contrary.

linprocfs, but it lies anyway.  I've engaged in hacks like this in 4.x,
but I think they are just that: hacks.  I think a real fix is to support 
turning off CPUs in the MI code and allow userland to query via a non-hackish 
interface how many CPUs are actually enabled and get appropriate load stats, 
etc. based on that.

-- 
John Baldwin


More information about the cvs-src mailing list