Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp3813828imm; Mon, 30 Jul 2018 04:05:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcbxxlS1p7TDwpDmDjap7MeP6rgeTNOP10SCrx5Bf4iVBtd2B+OnOlGBzL8WcRgrhovJRt5 X-Received: by 2002:a62:e00a:: with SMTP id f10-v6mr17445667pfh.208.1532948702653; Mon, 30 Jul 2018 04:05:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532948702; cv=none; d=google.com; s=arc-20160816; b=X3o2d+JkcRs+53+l3szUYxQXQTCilMRvdpdTh/EGHKl/nbK90nzPriZP6ERTM7M2tb wQ9enhr7or5F0UfcuFiirCKe7bzxsj/zJIuPBMF8XSAP327v7+fuCTuKSp4qUVkOKEbK gyZL24DNuK6EGMuhFYpRyqUxRRLbda9Fgf5LydqNp5b8tPPT3Y18ruzjl3bn6PBR9coF t7RU+iSRC8Pgtdz4uA6ASVDwfiRWerhJMV3JKw7J6xTr/yAqXTTZOwjkH9sjXeoiUZgt j4PlOn/eQsNNvNzeMc8mTmNojb/GTz4F5PyF2YG1hBD3aCDmjWkyxS/y0rYSg3au6M4N A2wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=gHcqHoO/7EjL3S3nz1yQDXzosDa+6+KZerzClwS36eU=; b=uKoejQrblXYECezl+F/N8Rt6PuRVOAW1LJSokqOxZZYcXnCM+J+oO4CQnUSIiRAz9/ 457NfNdXINYNnidD+Q4HRzSjxfltYJN19pMvYEsgrSftpS0FcMUXYekcdqg0WcqqzxME qjveWAaZrkAreoU1onpxb/sa3LBJvMc9MEvoZJvbX+wYjgQCm0HRckumotCVQnXKL0HL rRaEAERlRQ1HHLci8fqQcJ137l7ualJQ3I8q97guXZfw89Z4vcAG//bB5I7dJCA3AO66 Q0jDSi3Dv2mTPk5fUrQPUKjfVt7T5VbpRqmMQN4JHTq6v1UXz5trPfVZNo8ogUhf9JFp i0lQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b31-v6si10705319pgl.437.2018.07.30.04.04.45; Mon, 30 Jul 2018 04:05:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727357AbeG3Mht (ORCPT + 99 others); Mon, 30 Jul 2018 08:37:49 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:55762 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726530AbeG3Mhs (ORCPT ); Mon, 30 Jul 2018 08:37:48 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fk5xM-0006ps-Fu; Mon, 30 Jul 2018 13:03:16 +0200 Date: Mon, 30 Jul 2018 13:03:16 +0200 (CEST) From: Thomas Gleixner To: Xu YiPing cc: john.stultz@linaro.org, sboyd@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] timers: fix offset calculation when the expires align with LVL_GRAN In-Reply-To: <1532669610-103892-1-git-send-email-xuyiping@hisilicon.com> Message-ID: References: <1532669610-103892-1-git-send-email-xuyiping@hisilicon.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Jul 2018, Xu YiPing wrote: > when the expires of timer is align with LVL_GRAN(n), it will be trigged > in 'expires + LVL_GRAN(n)'. > > Some drivers like power runtime use the timer to start a power down > of device, it could saves power if the timer is triggerd in time, > especially when LEVEL=0 with low expires. From the above I have no idea what you are trying to 'fix', but see below. > Signed-off-by: Xu YiPing > --- > kernel/time/timer.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/time/timer.c b/kernel/time/timer.c > index cc2d23e..76655e2 100644 > --- a/kernel/time/timer.c > +++ b/kernel/time/timer.c > @@ -487,7 +487,8 @@ static inline void timer_set_idx(struct timer_list *timer, unsigned int idx) > */ > static inline unsigned calc_index(unsigned expires, unsigned lvl) > { > - expires = (expires + LVL_GRAN(lvl)) >> LVL_SHIFT(lvl); > + expires = (expires + LVL_GRAN(lvl) - 1) >> LVL_SHIFT(lvl); > + > return LVL_OFFS(lvl) + (expires & LVL_MASK); This is fundamentally wrong. Assume the following scenario: base->clk = 1; timer->expires = 1; __internal_add_timer(base, timer) { idx = calc_wheel_index(timer->expires, base->clk) { delta = expires - clk; if (delta < LVL_START(1)) idx = calc_index(expires, 0) { expires = (expires + LVL_GRAN(0) - 1) >> LVL_SHIFT(0); return LVL_OFFS(0) + (expires & LVL_MASK); Now lets use real numbers: __internal_add_timer(base, timer) { idx = calc_wheel_index(1, 1) { delta = 1 - 1; <- 0 if (0 < LVL_START(1)) idx = calc_index(1, 0) { expires = (1 + LVL_GRAN(0) - 1) >> LVL_SHIFT(0); ----> expires = 0 return LVL_OFFS(0) + (0 & LVL_MASK); ----> 0 So the returned index is 0, which means that the timer will expire in LVL_SIZE - 1 == 63 ticks. The above example is the worst case, but you broke other assumptions as well. The timer wheel guarantees that a timer armed with: mod_timer(timer, jiffies + 1) will not fire before aty least one jiffy has elapsed. Let's look at the time line: |-------------------|-------------------|----------------| tick tick tick jiffies jiffies + 1 jiffies + 2 | | | Any timer armed | ^ | here must be | | | queued here -------------------------| in order to guarantee that. Timer wheel timers are not accurate and never can be. Thanks, tglx