Re: STI, HLT in acpi_cpu_idle_c1

:>     This sounds like a disaster waiting to happen to me.  ACPI barely works
:>     on UP systems, there is no way I would ever trust it to properly HLT or
:>     otherwise screw around with the cpu timing on an SMP system.  HLT is
:>     plenty good enough.  IMHO this type of feature is not something that
:>     should be turned on by default on SMP.
:
:Certain large CPU vendors disagree.
:
:http://www.theinquirer.net/?article=16739
:
:-- 
:John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/

    John, the vast majority of people who run FreeBSD almost certainly
    (A) don't care and (B) would just rather the machines work and (C) do
    not run clusters with thousands of MP machines.

    If certain large CPU vendors want to turn on the feature, they can turn
    it on.  If you want to create a special 'big-vendor' release then you
    can create a special big-vendor release.  But turning it on by default
    is just plain a bad idea.  It creates unnecessasry additional pain on
    a system that already has enough pain to deal with.  It is an unnecessary
    imposition on your user base.

    This isn't about the existance of the feature, this is about setting a
    reasonable default so you don't have to be rocket scientist to run
    FreeBSD-5 reliably.    There are serious problems with ACPI.  We have
    FreeBSD-5's ACPI in the DragonFly tree (not on by default) and I've
    played with everything through the acpica-unix-20040211 dist and it
    is a horrendous mess.  It's a miracle that it works at all.

    And, for that matter, WITNESS should either be turned off by default
    (not just for releases), or it should be fixed to not impose such
    horrendous overheads.  Are the mutex abstractions and use of those
    abstractions so unstable, even after all this time, that WITNESS is
    going to have to stay in the tree forever?  Maybe you should start
    rethinking some of those abstractions.

    You guys don't have to listen to me, god knows I'm sure many of you don't
    any more, but while I don't have solutions to the ACPI mess (other then
    to turn off by default those features that are not absolutely required),
    I sure as hell do have solutions to the IPI and SMP rendezvous mess - we
    have a ground-up designed API (our IPI messaging API) that *WORKS*
    without deadlocking anything in DragonFly.  It forms the basis for all IPI
    operations in DragonFly and is used by half a dozen core subsystems.
    It would even be fairly easy to port if someone over there made the
    effort and if you ripped out some of the more ridiculous features
    (such as preemptive migration across cpus while in kernel mode and
    preemptive non-interrupt thread scheduling as a side effect from an
    interrupt blocking on a mutex and priority borrowing).  All that junk
    is not making FreeBSD-5 any faster, they're just hacks on top of hacks
    to get around fundamental, serious problems with the mutex and
    fine-grained locking model that you are trying to implement.

						-Matt