Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp514755imm; Wed, 1 Aug 2018 00:12:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdMI3n5t0wk3lkwPu3O8MGfpUNhhQGGY266qjonRI57232BC55KvwZ0AHiKCzGWB/SG8ZmN X-Received: by 2002:a63:1e66:: with SMTP id p38-v6mr23252425pgm.376.1533107535468; Wed, 01 Aug 2018 00:12:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533107535; cv=none; d=google.com; s=arc-20160816; b=xqZZDscUanFHH+F1kJTzsbKZBag/2f24PyoOukxYCSgumJ+1+Eg8wmcLPe2vW0HqN4 GL9fG9ZecWw/qRFs4cd5ZbbfW9DC/mY0QDnbdFe9sOMwCpKXfn5U8Jq04aLgeoCKu8Lc 6P/5w4KpB2/y9bZEYKpoZucvWDi3G0jSAabfWxxa1ESshTXQ7yGuuWrJidqrzeQZDJjs OCWglW4vuqzxEkIptTAzAgoMmSY19uM0AwhAIT3YJuI0KsnYzDfaHFdTICbAS5us3Ysd Q8JrruYIgIAW57j74jIBeDCgeMVmEznLSof9vBTwwSQYx0syfdZI9v/bhpH6hI1bvXAz oxyA== 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=0Uj27UkXzC4jGafuLRCxOvSQJ4g4g9ZpssRkcX2ZQWw=; b=Hz/7VJ+9ILYzMXPvi9jrtrABxQbN2x6YavSGZmK2n/luN9hwF5xwkET8GJ2poFVVxg 32HXmEkIXbPWaaELDc1o7zzlM6Y9eYE11/pW4yUnD+gPbEXa5uv0kyNY+tJiky8u1fvE z8YVFETu+PpCiubP2pKf6jlvWvDpE0qt6MHHlaRaNxDul+t5wn1kvglLg1NKFErBUkkX qcRWveWdAXDq3VKVgH2HwnHKmYB302M1w7vVZEFXliXPf8JhXAJRihceOTlPFnJqt+Yh 9YKBJDVr9JfKLpqJYLV1mC4wsVJv5mZr+vOmUVUAtebm7RGxR2ShTpor+1mUJfeoIjh8 i4zQ== 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 m9-v6si16052034pga.456.2018.08.01.00.12.01; Wed, 01 Aug 2018 00:12:15 -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 S1733154AbeHAIzS (ORCPT + 99 others); Wed, 1 Aug 2018 04:55:18 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:33172 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733096AbeHAIzS (ORCPT ); Wed, 1 Aug 2018 04:55:18 -0400 Received: from p4fea5a5a.dip0.t-ipconnect.de ([79.234.90.90] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fklHd-0000ie-3q; Wed, 01 Aug 2018 09:10:57 +0200 Date: Wed, 1 Aug 2018 09:10:56 +0200 (CEST) From: Thomas Gleixner To: Xu YiPing cc: John Stultz , sboyd@kernel.org, LKML , anna-maria@linutronix.de Subject: Re: [PATCH] timers: fix offset calculation when the expires align with LVL_GRAN In-Reply-To: <86709eae-fa35-e36a-cafd-2c917d188276@hisilicon.com> Message-ID: References: <1532669610-103892-1-git-send-email-xuyiping@hisilicon.com> <86709eae-fa35-e36a-cafd-2c917d188276@hisilicon.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 Aug 2018, Xu YiPing wrote: > On 2018/7/31 22:34, Thomas Gleixner wrote: > > > > > > On Tue, 31 Jul 2018, Thomas Gleixner wrote: > > > >> On Tue, 31 Jul 2018, Xu YiPing wrote: > >>> On 2018/7/30 19:03, Thomas Gleixner wrote: > >>>> > >>>> __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 > >>> > >>> LVL_GRAN(0) = 1 and LVL_SHIFT(0) = 0 > >>> > >>> after the calculation, expires = 1 ? > >> > >> Indeed. You're right. Math is hard... So the index would be 1 and still not > >> fulfil the below: > > > > Hmm, crap. Let me think about it some more. 34C is way too hot to think. > > > > when the expire is aligned with LVL_GRAN(x), it could be triggered at expire, > no need to wait another LVL_GRAN(x). > > just a little improvement, useful when expire is small. The expire early problem still persists: schedule_timeout(x) expires = jiffies + x; mod_timer(timer, expires); This will return _BEFORE_ X jiffies have elapsed in 99% of the cases, so it's not a little improvement, it's a big regression. Again for schedule_timeout(1): |-------------------|-------------------|--------------------| tick tick tick jiffies jiffies + 1 jiffies + 2 | | | Any timer armed | ^ | here must be | | | queued here -------------------------| | | | Any timer armed | ^ | here must be | | | queued here -------------------------| The only case where your change would be correct is if _all_ timers are armed exactly at the jiffies boundary. Can you guarantee that? Not at all. And even hrtiemrs suffer from this issue when high resolution mode is disabled because then they are expired on the tick boundary as well and if the expiry time is past the current time at the tick boundary then the timer will be expired one tick later. It's a fundamental property of timers which are driven by a periodic tick and you can argue in circles it wont change. Thanks, tglx