From owner-freebsd-bugs@FreeBSD.ORG Sun Sep 1 06:50:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 71498DC9 for ; Sun, 1 Sep 2013 06:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DC542A23 for ; Sun, 1 Sep 2013 06:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r816o14L049650 for ; Sun, 1 Sep 2013 06:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r816o1CK049597; Sun, 1 Sep 2013 06:50:01 GMT (envelope-from gnats) Date: Sun, 1 Sep 2013 06:50:01 GMT Message-Id: <201309010650.r816o1CK049597@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andriy Gapon List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 06:50:01 -0000 The following reply was made to PR kern/181632; it has been noted by GNATS. From: Andriy Gapon To: Mike Harding , bug-followup@FreeBSD.org Cc: Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower Date: Sun, 01 Sep 2013 09:39:46 +0300 on 31/08/2013 20:05 Mike Harding said the following: > I reverted the single line at > > http://svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi_cpu.c?annotate=244616&pathrev=244616#l978 Thank you for narrowing this down! > Given that the code says > > /* If disabled, take the safe path. */ > 977 if (is_idle_disabled(sc)) { > 978 acpi_cpu_c1(); > 979 return; > 980 } > > > and then does a 'hlt' or idle if idle is disabled, this might be a problem. But it should not be a problem. First, is_idle_disabled should not be normally set. It is supposed to be set only during short transitional periods. So it would be useful to understand why it is set (after resume) and makes the difference. Second, "idle is disabled" means that the ACPI C-state machine is disabled, not that the system must not idle at all. In fact, being in this function (acpi_cpu_idle) means that the system explicitly wants to idle. Using hlt to idle is the right / normal / safe thing. Not using hlt means that the system keeps burning cycles even when it has nothing to do. So with your change you should observe increased power consumption and heat production. So, this is another mystery as to why the perfectly normal use of hlt affects your system so badly. P.S. I hope that you noticed a list of things to look at in my previous followup to this PR. -- Andriy Gapon