From owner-freebsd-current@FreeBSD.ORG Tue Jun 22 22:41:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9A4316A4CE; Tue, 22 Jun 2004 22:41:49 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F9D343D3F; Tue, 22 Jun 2004 22:41:49 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i5MMfJx7042207; Tue, 22 Jun 2004 15:41:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i5MMfJk7042206; Tue, 22 Jun 2004 15:41:19 -0700 (PDT) (envelope-from dillon) Date: Tue, 22 Jun 2004 15:41:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200406222241.i5MMfJk7042206@apollo.backplane.com> To: John Baldwin References: <200406221708.32433.jhb@FreeBSD.org> <200406222134.i5MLYQ9O041828@apollo.backplane.com> <200406221805.44339.jhb@FreeBSD.org> cc: current@FreeBSD.org cc: Julian Elischer Subject: Re: STI, HLT in acpi_cpu_idle_c1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 22:41:50 -0000 :> 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 <>< 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