From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751746AbcFVDBr (ORCPT ); Tue, 21 Jun 2016 23:01:47 -0400 Received: from mail-yw0-f173.google.com ([209.85.161.173]:34819 "EHLO mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751513AbcFVDBp (ORCPT ); Tue, 21 Jun 2016 23:01:45 -0400 MIME-Version: 1.0 In-Reply-To: References: <1466154816-17900-1-git-send-email-zhaoyang.huang@spreadtrum.com> <1466154816-17900-2-git-send-email-zhaoyang.huang@spreadtrum.com> From: Zhaoyang Huang Date: Wed, 22 Jun 2016 11:01:06 +0800 Message-ID: Subject: Re: [RESEND PATCH v2 2/2] power/idle: enhance the precision of sleep_length To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, =?UTF-8?B?Wmhhb3lhbmcgSHVhbmcgKOm7hOacnemYsyk=?= Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20 June 2016 at 09:14, Zhaoyang Huang wrote: > On 17 June 2016 at 19:50, Thomas Gleixner wrote: >> On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >>> On 17 June 2016 at 17:27, Thomas Gleixner wrote: >>> > On Fri, 17 Jun 2016, Zhaoyang Huang wrote: >>> >> There should be a gap between tick_nohz_idle_enter and >>> >> tick_nohz_get_sleep_length when idle, which will cause the >>> >> sleep_length is not very precised. Change it in this patch. >>> > >>> > What kind of imprecision are we talking about? Seconds, nanoseconds or >>> > lightyears? >>> > >>> > Your changelog lacks any form of useful information. >>> > >>> sorry for the confusion. The imprecision can be caused by, for >>> example, the callback function registered for CPU_PM_ENTER, which may >>> consume a period of time within the 'idle' time. Besides, I also >>> wonder why not calc the 'sleep_length' in the >>> tick_nohz_get_sleep_length? This value is calculated at very >>> beginning of the idle in current approach. >> >> You still are not explaining the amount of imprecision. What are you talking >> about and is it really relevant in any way or are you just trying to solve an >> acedemic issue? >> >> Thanks, >> >> tglx >> > Indeed, it is depends on how deep the idle state is. For example, the > lightest level for my current platform is 1100us, which sums up the > entry,exit and min time. However, there is a callback which do memory > management(merge the same page) in CPU_PM_ENTER will consume at least > 500us. In current approach, it cause 50% imprecision for this level of > idle state. Hi Thomas, Any further comments on that?