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