Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4457639pxj; Wed, 12 May 2021 06:11:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWSlbCfNQeNIZDoSce/m7l3XTXiJ4EZJ7mLdfuDAVeIn3mEkq8G/GFUvowOngiUyndAvvR X-Received: by 2002:aa7:c150:: with SMTP id r16mr42528137edp.82.1620825106109; Wed, 12 May 2021 06:11:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620825106; cv=none; d=google.com; s=arc-20160816; b=hL5xfH2MHzFj7CQMaxmid20EKh0f9wu7jis9BtUNpWmqyCVUVMw6e1cq0YmVgAvzsC JB3HVXcidMSidpJXvczda3T0Q0PhiXIEyu7T9X6s4LL2BI9463U4KLz++N6SH7TxJxHW CMlzkQaTGTpo15UnM+7+vNP/E7LUveI2w0zwGpqqpi/zkH3Z/S4TMFA+jhkqFY3eDZMF 9XR24NkR6/wlD/olIPgti0uaaiWfPY4v3y/yKtglIaBMXj7CGIjmmimzG5Vnyk1Jdbzl 0+zj0gyIB8iDULltQDzpT9/lupItpB3xJXdurZwjO1HQ8FIYgOsSCwcg5VaxAePnGM5C zpsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=F+55qr4PgxpthYJseTbnPILMll0U05P9x4R1AOJHuR0=; b=ixnLw3hEYczjgAgzyC6nxus74SUdoN3bYwT5yTg+2kdJ5Ifpaoblziv/WueApZgHwq 1lcdqYbOUFawAtI/Z595ADDp6jVZDZjDWQAToUhPmx1+3Wj9D4mjPkpNbUE4+zy16iWq fiNTPRMpTDcia4uDrLAFogSJtz2U3p3pthj2jix3rTwQ0RmlqClr5h0+b4cEl96/DpQI a1R2EpI8Eo+rk6Z7JJcVObFL8vIX2+TsaJhafgpvN/BOQAsWjf2eKDebgB3srvfFC2X5 VNjaClhG2qhCfDXsduyePthW8UaTw5SSDjsAWg8rWd3Jr4DWFpWQ7IdQdwPqcXLgJ5bg BxOQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y15si19522029ejw.376.2021.05.12.06.11.20; Wed, 12 May 2021 06:11:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231989AbhELM1D (ORCPT + 99 others); Wed, 12 May 2021 08:27:03 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:2463 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231984AbhELM1D (ORCPT ); Wed, 12 May 2021 08:27:03 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4FgDTX6s52zBtV5; Wed, 12 May 2021 20:23:12 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.498.0; Wed, 12 May 2021 20:25:45 +0800 From: Xiongfeng Wang To: , , CC: , Subject: [RFC PATCH] timer: Fix bucket_expiry calculation Date: Wed, 12 May 2021 20:15:29 +0800 Message-ID: <1620821729-40694-1-git-send-email-wangxiongfeng2@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When I use schedule_timeout(5) to put a process into sleep on my machine with HZ = 100. It always sleep about 60ms. I enable the timer trace and find out, when the timer_list expires, 'now' is always equal to 'expires + 1'. I print 'base->next_expiry' in '__run_timers' and find out 'next_expiry' is always equal to 'expires + 1'; my_test_thread-1230 [001] d... 382.627089: timer_start: timer=000000004ec021c9 function=process_timeout expires=4294975072 [timeout=5] cpu=1 idx=33 flags= -0 [001] ..s. 382.687082: run_timer_softirq: jiffies 4294975073 next_expiry 4294975073 -0 [001] ..s. 382.687083: timer_expire_entry: timer=000000004ec021c9 function=process_timeout now=4294975073 baseclk=4294975073 my_test_thread-1230 [001] d... 382.687089: timer_start: timer=000000004ec021c9 function=process_timeout expires=4294975078 [timeout=5] cpu=1 idx=39 flags= -0 [001] ..s. 382.747083: run_timer_softirq: jiffies 4294975079 next_expiry 4294975079 -0 [001] ..s. 382.747084: timer_expire_entry: timer=000000004ec021c9 function=process_timeout now=4294975079 baseclk=4294975079 It is because we use the following equation to calculate bucket_expiry. bucket_expiry = ((expires + LVL_GRAN(lvl)) >> LVL_SHIFT(lvl)) << LVL_SHIFT(lvl) 'bucket_expiry' is equal to 'expires + 1' when lvl = 0. So modify the equation as follows to fix the issue. bucket_expiry = ((expires + LVL_GRAN(lvl) - 1) >> LVL_SHIFT(lvl)) << LVL_SHIFT(lvl) Signed-off-by: Xiongfeng Wang --- kernel/time/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index d111adf..a6a26da 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -501,7 +501,7 @@ static inline unsigned calc_index(unsigned long expires, unsigned lvl, * * Round up with level granularity to prevent this. */ - expires = (expires + LVL_GRAN(lvl)) >> LVL_SHIFT(lvl); + expires = (expires + LVL_GRAN(lvl) - 1) >> LVL_SHIFT(lvl); *bucket_expiry = expires << LVL_SHIFT(lvl); return LVL_OFFS(lvl) + (expires & LVL_MASK); } -- 1.7.12.4