From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753385AbcFQPyN (ORCPT ); Fri, 17 Jun 2016 11:54:13 -0400 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:58583 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbcFQPyK convert rfc822-to-8bit (ORCPT ); Fri, 17 Jun 2016 11:54:10 -0400 From: Jisheng Zhang To: "Rafael J. Wysocki" CC: Peter Zijlstra , "Paul E. McKenney" , "Rafael J. Wysocki" , "Viresh Kumar" , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List Subject: RE: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early") Thread-Topic: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early") Thread-Index: AQHRyK1jr0enS8HWkEWC6eDb0vCMaZ/uQS8AgAAApAD//4xP4w== Date: Fri, 17 Jun 2016 15:53:40 +0000 Message-ID: <393b63b7caa7474a97baf248c4891b72@SC-EXCH02.marvell.com> References: <20160617163023.5bb374f8@xhacker> <20160617164054.6339c5d4@xhacker> <20160617131651.GU3923@linux.vnet.ibm.com> <20160617140353.GQ30154@twins.programming.kicks-ass.net> <2c6f6aab934141e08d9636739a9f7a94@SC-EXCH02.marvell.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.36.250.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-17_09:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606170182 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Rafael, I used intel_pstate. I just tested v4.7-rc3, which should include commit 4578ee7e1def intel_pstate: Avoid unnecessary synchronize_sched() during initialization, I can still get the same wakeups, so it's not sufficient. Another clue maybe helpful, I found these top2 wakeup/s is consistent, e.g rcu_sched always gives about 10 wakeups/s, and tick_sched_timer gave 5.6-5.9 wakeups/s, 144.3 µs/s 10.0 Process [rcu_sched] 193.9 µs/s 5.7 Timer tick_sched_timer Thanks, Jisheng ________________________________________ From: Rafael J. Wysocki Sent: Friday, June 17, 2016 23:42 To: Jisheng Zhang Cc: Peter Zijlstra; Paul E. McKenney; Rafael J. Wysocki; Viresh Kumar; linux-pm@vger.kernel.org; Linux Kernel Mailing List Subject: Re: regression caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early") On Fri, Jun 17, 2016 at 5:40 PM, Rafael J. Wysocki wrote: > On Fri, Jun 17, 2016 at 5:32 PM, Jisheng Zhang wrote: >> Hi all, >> >> First of all, sorry for top post, only webmail is available now. >> >> Second, sorry again for report incorrect commit, I were too tired this morning so I remember the wrong commit. The regression is caused by bb6ab52f2bef ("intel_pstate: Do not set utilization update hook too early"), so I update the email title. > > OK, that makes much more sense. :-) > > And > > 4578ee7e1def intel_pstate: Avoid unnecessary synchronize_sched() > during initialization > > is not sufficient I suppose? I mean, it is not sufficient to reduce the number of wakeups again?