From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 7 18:05:18 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7121106564A; Thu, 7 Jun 2012 18:05:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BA8D28FC15; Thu, 7 Jun 2012 18:04:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA22855; Thu, 07 Jun 2012 21:04:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Sch4n-000DE2-6R; Thu, 07 Jun 2012 21:04:53 +0300 Message-ID: <4FD0ED44.9040402@FreeBSD.org> Date: Thu, 07 Jun 2012 21:04:52 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120503 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexander Motin References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> <4FBFDFFB.9020501@FreeBSD.org> <4FBFE624.1020208@FreeBSD.org> <20120526090233.f638c1d2.lists@yamagi.org> <4FC0A3A1.80200@FreeBSD.org> <4FC7D464.20602@FreeBSD.org> <4FCFD2A1.60706@FreeBSD.org> <4FCFE178.9080505@FreeBSD.org> <4FD061F8.6030905@FreeBSD.org> <4FD06885.4050507@FreeBSD.org> In-Reply-To: <4FD06885.4050507@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 18:05:18 -0000 on 07/06/2012 11:38 Alexander Motin said the following: > On 06/07/12 11:10, Andriy Gapon wrote: >> on 07/06/2012 02:02 Jung-uk Kim said the following: >>> Any way, hwpstate still isn't quite right even without your patch. >>> >>> sys/kern/kern_cpu.c cpufreq_curr_sysctl() -> CPUFREQ_SET() -> /* for all >>> CPU devices */ cf_set_method() -> /* thread_lock(), sched_bind(), ... */ >>> CPUFREQ_DRV_SET() -> sys/x86/cpufreq/hwpstate.c hwpstate_set() -> >>> hwpstate_goto_pstate() /* for each CPU unit */ /* thread_lock(), >>> sched_bind(), ... */ >> >> Oh, I didn't realize that there was the cpufreq-level loop over all CPUs! >> That really sucks. >> >> Maybe some day we should accept that different CPUs could legitimately be in >> different P-states and provide support for that throughout the stack (from >> powerd to drivers). > > Support for different P-states on different CPUs can be useful if CPUs have > different capabilities. Not sure what you mean... I was talking about setting different CPUs to different P-states based on the per-CPU conditions (e.g. utilization). I certainly didn't mean to talk about heterogeneous P-state definitions or any other heterogeneous silicon issues. > I believe it is very rare, but possible. At this moment > cpufreq should set for each CPU frequency closest to one that was set on BSP. It > should be possible to make powerd to read sets of frequencies from all CPUs and > do the same, just more intelligently. > > Same time using very different frequencies for different CPUs can IMHO be very > problematic even in theory. For SMP systems it is quite difficult (because of > threads migration and possible inter-operations of multiple threads) to identify > cases when even global frequency can be reduced without proportional performance > penalty. Making in per-CPU multiplies number of options and requires awareness > from the scheduler. I humbly disagree. I think that it's not a job of scheduler to be overly smart when power-saving policies are in effect. IMO, scheduler should just do its own job and powerd should react to individual loads of CPUs. Where latencies really matter there powerd should not be used (or perhaps used with some different policy skewed towards performance vs economy). Also, Linux does it, so it must at least doable :-) -- Andriy Gapon