Received: by 2002:a05:6a10:83d0:0:0:0:0 with SMTP id o16csp147560pxh; Thu, 7 Apr 2022 16:58:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSqaGw1Wr/9KPiMbS5tgEYgW72fKfuNXk7EbN2lgVtt2WJBVZWoRq3lkSOCubn1/eTfyqa X-Received: by 2002:a17:902:b684:b0:156:80b4:db03 with SMTP id c4-20020a170902b68400b0015680b4db03mr16686663pls.16.1649375897438; Thu, 07 Apr 2022 16:58:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649375897; cv=none; d=google.com; s=arc-20160816; b=hLHH+SUAk3lrRnKPK7M8GjXVaoGz9xxJCSlH1j2Bh+Og3M7inDKQigX7xZuEaVcCQd xg11YjC9XwEVgs56er6rzyeDYYDxHp2bwpYBS6R7gKcpHO5TBA+Wujv2gQFDfWf021x7 FKSjaWD7z4ZOjIswd9GfpqxLcCuWOQN+umwZGPDhegZyJb+X3E4aSB/vgZhF8BL6kbyq f/qy9XlLELvgEYd3mv1x1uH2GLHXMV4GT3rb79uQE9/lj/3ctclnHAOGJ4Rf5ZrEZ8iO doVbty1f3ig/FYDz07poXDeiiO0BYWj0WNryXKEUdjV+JOOsgTC6c9giCI0yWceWzXaS cmmQ== 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:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=16Wm5toPM4kAJCuxIXvu2q58XH/MGF2r50DMfTvAbJ0=; b=gieqULGfyxjJgHyZ7HV4DwvS2ZegEsCr0FKTIbJ19bGSnQ8H5XUiRSc+hcDqeqYJrg YjmOx6IMp1UMBMvY9tSgpShzfmLp18mBRgIgQhurQtQtJQsVC99T4MZBgdt+viwbuu45 buwGc6mWL9pILV8Jc4FnRy/tInUAIpvs0YDF1QKPR34HOmDGvzORAf+H3PBfA0qAQI+U PxLJcdnql93aSvLN/HnpbSkWk9igvp2purYDLEiUIOoKpZRD4YV7emdBCQmQDTZTVnrC Qi2WdEP930hKCLH0GHFoV1TvEkmqXqAMprfTKd4TQXD7SCGA9YTsKK/Oe4Jt88VaisDd cNxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=zQl8Xb55; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id b8-20020a170903228800b00153c1012914si1139177plh.181.2022.04.07.16.58.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Apr 2022 16:58:17 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=zQl8Xb55; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4BF6727681D; Thu, 7 Apr 2022 16:27:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232515AbiDGX3J (ORCPT + 99 others); Thu, 7 Apr 2022 19:29:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230329AbiDGX3F (ORCPT ); Thu, 7 Apr 2022 19:29:05 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB9D1267F9B; Thu, 7 Apr 2022 16:27:00 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649374017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=16Wm5toPM4kAJCuxIXvu2q58XH/MGF2r50DMfTvAbJ0=; b=zQl8Xb55m/PzcH1z8OBaTXDEGh5P6zp4UoiI3CayAWBXEexzQamzky/2SoF2mHwvaXTJLz 6wh0Rd67vsU1mor8dFkySo069KqTF+u7gfGY0Ej2TpzLNifuY7u/ZOSp+WmzB4VQJMMJ0b LrSJqF5LV803fxPHRFr0JPFMqhTfQ79QXJiwny1TG0TSAsonCH3BGhd9I6YiXE5xvfSYKy YzNus3AKevUD9PfwRNlcI49Dt7YUozcXf3J2iKqSt0DU3Gdlwbl2K2zkdKqeLsLzKi/5rg CB+yhcmjN5M5hgj/ve7H8445eGQBR5yiobGMoDVWvRwaEd4GQ2xHOh+AVAwKGg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649374017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=16Wm5toPM4kAJCuxIXvu2q58XH/MGF2r50DMfTvAbJ0=; b=HGCCE5bNMMDMKUM8JNgVXr0Khy3LhmuSUKwD0Ngo4ahODDcqfgiO0xtBl5wrGLdava0d9r VV7vpDL8D7NqYuCg== To: Artem Savkov Cc: Anna-Maria Behnsen , netdev@vger.kernel.org, Josh Poimboeuf , davem@davemloft.net, yoshfuji@linux-ipv6.org, dsahern@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] timer: add a function to adjust timeouts to be upper bound In-Reply-To: References: <871qyb35q4.ffs@tglx> Date: Fri, 08 Apr 2022 01:26:56 +0200 Message-ID: <8735iolbjz.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 06 2022 at 11:52, Artem Savkov wrote: > On Tue, Apr 05, 2022 at 05:33:23PM +0200, Thomas Gleixner wrote: >> On Sat, Apr 02 2022 at 08:55, Artem Savkov wrote: >> > Is it possible to determine the upper limit of error margin here? My >> > assumption is it shouldn't be very big, so maybe it would be enough to >> > account for this when adjusting timeout at the edge of a level. >> > I know this doesn't sound good but I am running out of ideas here. >> >> Let's just take a step back. >> >> So we know, that the maximal error margin in the wheel is 12.5%, right? >> That means, if you take your relative timeout and subtract 12.5% then >> you are in the right ballpark and the earliest expiry will not be before >> that point obviously, but it's also guaranteed not to expire later than >> the original timeout. Obviously this will converge towards the early >> expiry the longer the timeouts are, but it's bound. > > Ok, I was trying to avoid a "hole" where any timeout < LVL_GRAN(lvl) > would be always substantially (LVL_GRAN(lvl) - LVL_GRAN(lvl - 1)) early > but looks like this is unavoidable with this approach. Right, but where is the problem you are trying to solve? Does it matter whether the keepalive timer fires after 28 minutes or after 30 minutes? Not really. All you are about that it does not fire 2 minutes late. So what? >> Also due to the properties of the wheel, the lag of base::clk will >> obviously only affect those levels where lag >= LVL_GRAN(level). > > Is this true? Won't it be enough for the lag to be just > lag >= (LVL_START(lvl) - adjusted_timeout) for the cases when we cross > level boundary on adjustment? The corner case is at the next boundary level. The resulting worst case there is one jiffy, which is below noise level :) Thanks, tglx