STI, HLT in acpi_cpu_idle_c1
dillon at apollo.backplane.com
Tue Jun 22 22:41:50 GMT 2004
:> 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.
: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.
More information about the freebsd-current