From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 7 08:38:35 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 BB485106564A; Thu, 7 Jun 2012 08:38:35 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 86DE88FC0C; Thu, 7 Jun 2012 08:38:34 +0000 (UTC) Received: by bkvi18 with SMTP id i18so348139bkv.13 for ; Thu, 07 Jun 2012 01:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ERyFbkuNwCmzNOKV3QtMfkEBmQAQj3eOzYZNCA2wypk=; b=pV6umtVrQvV21vAdsjgO2HnitkIK3kN5m4FgJMRZgE3PxL04mqxTXUxsLVBybhq3KE uYjJw+LSnW4F+pXO/+2dVSUV/x3VOpFPoOeghqdmGMpAj8XKCQiuGwZzfks94WqrJ6IQ 9BLgrISIbjIt27K0QRQweJn+ctWcKupUIMKFIWW5kFf220OWKIk+aQOKqzHjoHRRvMjq YJRYSnXnILsWkKhZ+s0w5+vFt/P/7QkxI1H4mdOwu1rmGrHwkdBXVu8jJiA577V7KJjQ jv19wXGctyz9PLYvFYlot/oLj+cYmK9VdOhuJVOEe0ibdm3dMq8lcWVLHj3WYpXJipHS hzoA== Received: by 10.205.137.5 with SMTP id im5mr768348bkc.45.1339058313299; Thu, 07 Jun 2012 01:38:33 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id n19sm2602990bkv.14.2012.06.07.01.38.30 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 01:38:32 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FD06885.4050507@FreeBSD.org> Date: Thu, 07 Jun 2012 11:38:29 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120506 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon 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> In-Reply-To: <4FD061F8.6030905@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, freebsd-acpi@FreeBSD.org, sbruno@FreeBSD.org, Yamagi Burmeister , seanbru@yahoo-inc.com, Jung-uk Kim 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 08:38:35 -0000 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. 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. -- Alexander Motin