Re: CPU utilization

Julian Elischer wrote:
Robert Watson wrote:

On Thu, 12 Apr 2007, Dag-Erling Smørgrav wrote:

Randall Stewart <rrs@xxxxxxxxx> writes:
machdep.hyperthreading_allowed: 0

Note that enabling hyperthreading is more likely to harm performance than to help it. You should just disable it in the BIOS, and run a UP kernel.

Historically this has been true, but some more recent results I've seen suggest that both hyperthreading hardware has improved, and the efficiency of our SMP implementation and scheduler has lead to it being more effective used. I would reevaluate this on more modern hardware and using a more recent kernel before assuming this remains true for your application.

In addition to this, to answer the original question, I remember a commit so that if you disable a cpu (or HT cpu) it doesn't get counted
in the CPU % so if you have 2 cpus and disable one hten prior to that
commit it was not possible to get > 50% busy but after that commit
you could get 100% "of the available CPUs". That fix is not (I believe)
in 6.2.

That's correct. The fix went in after RELENG_6_2 has been branched.

-Maxim

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: CPU utilization
    ... Note that enabling hyperthreading is more likely to harm performance than to help it. ... In addition to this, to answer the original question, I remember a commit so that if you disable a cpu it doesn't get counted ... Usually with normal work it was a was or a loss. ...
    (freebsd-current)
  • [PULL] x86 cpumask updates (plus a few generic pre-req cpumask cleanups)
    ... numa, cpumask: move numa_node_id default implementation to topology.h, fix ... commit 4c50d9ea9ca9e46b65aeffed3e0d6f54ff38c8d4 ... int err; ... void sync_buffer(int cpu); ...
    (Linux-Kernel)
  • Re: Warning during suspend with MS-7310 mainboard
    ... reverting the commit removes the warning ... with 2.6.31-rc4 and todays -git i get the following warning, which did not occur with 2.6.30 ... CPU 1 is now offline ... CPU0 attaching NULL sched-domain. ...
    (Linux-Kernel)
  • Re: [BUG 2.6.27-rc1] find_busiest_group() LOCKUP
    ... It's back to normal on 2.6.37-rc1 when reverting commit 50f2d7f682f9 ... Initializing cgroup subsys debug ... #2lockdep: fixing up alternatives. ... This also boots the other 16 CPU box that used to lockup in find_busiest_group. ...
    (Linux-Kernel)
  • [13/25] clockevent: Prevent dead lock on clockevents_lock
    ... commit f833bab87fca5c3ce13778421b1365845843b976 ... cpu B waits for clockevents_lock in clockevents_notifywith irqs disabled ... struct acpi_processor_cx *cstate) ... int broadcast) ...
    (Linux-Kernel)