Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3462188pxb; Mon, 4 Apr 2022 17:45:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwq/rmlUx9L7T+0kByhNp8d6/VKqJ+jNodOabWBX5P9nVeto6Ysk7JE+rcc6fnH77hQYRzc X-Received: by 2002:a17:90a:e50c:b0:1c7:c5e2:36e3 with SMTP id t12-20020a17090ae50c00b001c7c5e236e3mr988686pjy.245.1649119535383; Mon, 04 Apr 2022 17:45:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649119535; cv=none; d=google.com; s=arc-20160816; b=iP2/dwN63A+NBClz5o2ecnrUqtwnnunLpimLnN6kBS0UQBwwTzbAV2svoSI1OZFEhO yP3qTKEb1NoqmEr/RafWgxpDlcC8XA2Nr5i1oj+MRjZsA3EJpA4iHxLGkmCBpjafT4pJ GU4pdQ+Pj6LOCBB9jANuSvWWQVRfAHy+kquSmh/WTZgSFyi4jdYXAye3oP1rTKKDGItN YeHAkMUMAnbxu/u4hx/UALrCXTJgoaXBjYRj7c1uskQGF9FR0mRi6nMqCJdj1jH/UHQW LO0bVYKsCPAtIQ78f6iHjUmfpV11O0QPN3/cKEkvoK4jNTXL8F/bc5LRwmpvPxYTYYy6 VVyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BZ31gR6OuppI3OSuopIkD35xeUkys2Q81lOBmdyZewY=; b=zeH7hVp6noEQ/sHNTMjmanUdf3watUvNYvkiC5ouA93nkgoS+3RxKoitViPNOgcvDj MokI4YqtnBJs8wWNfPCv1075wuqPDd8ZNdY6Tg33+pX34j6ReRka3rCSbdjd38HM9cxS D9hzsgIJCbiyDmMRtHf38QVY68/hm9cwW8ueeimYXUfBI5S2m25v6qh4p/O8nSZZn67s eZ0FOT7bTHd1ZEBecqB4p3FYVUZEL9/qCXebMWvd7RbcFtekX6GKs/HbZtECFIaZnKNU 3og4NJO+AggX99z4qPYr1qM4Gp1QTNc5YFJr1c6/Ns5sT+J8QknFXO8U1e7T/ryAPDkz B5eg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VABP4MJi; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id q8-20020a170902dac800b00156bc861407si2360423plx.606.2022.04.04.17.45.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 17:45:35 -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=@redhat.com header.s=mimecast20190719 header.b=VABP4MJi; 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=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id AE1ADB6D06; Mon, 4 Apr 2022 16:57:27 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231932AbiDBG5j (ORCPT + 99 others); Sat, 2 Apr 2022 02:57:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229714AbiDBG5h (ORCPT ); Sat, 2 Apr 2022 02:57:37 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8D8A56586 for ; Fri, 1 Apr 2022 23:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1648882544; 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=BZ31gR6OuppI3OSuopIkD35xeUkys2Q81lOBmdyZewY=; b=VABP4MJiuUYmLNmMm7wXRG3j0p61x2Xt4q5QRbLus1P6W1ysw9q14cWnnJn33WnAUw/sOO UZyY38NQF+ygWbqyQkJ/QDvSvm2iZr71LZFSkUWVCRrLTmqmi0avJ9NbsgQf3NRI40bUK1 5OG15rjeTVLqJ2urRiS+ZhPVHdNaXtI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-642-xa1AZ-w_N4ewJCFCvH6KgA-1; Sat, 02 Apr 2022 02:55:41 -0400 X-MC-Unique: xa1AZ-w_N4ewJCFCvH6KgA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ACA5980A0AD; Sat, 2 Apr 2022 06:55:40 +0000 (UTC) Received: from sparkplug.usersys.redhat.com (unknown [10.40.192.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 172F720296A9; Sat, 2 Apr 2022 06:55:33 +0000 (UTC) Date: Sat, 2 Apr 2022 08:55:33 +0200 From: Artem Savkov To: Anna-Maria Behnsen Cc: netdev@vger.kernel.org, Thomas Gleixner , 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 Message-ID: References: <87zglcfmcv.ffs@tglx> <20220330082046.3512424-1-asavkov@redhat.com> <20220330082046.3512424-2-asavkov@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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, Mar 30, 2022 at 03:40:55PM +0200, Anna-Maria Behnsen wrote: > On Wed, 30 Mar 2022, Artem Savkov wrote: > > > Current timer wheel implementation is optimized for performance and > > energy usage but lacks in precision. This, normally, is not a problem as > > most timers that use timer wheel are used for timeouts and thus rarely > > expire, instead they often get canceled or modified before expiration. > > Even when they don't, expiring a bit late is not an issue for timeout > > timers. > > > > TCP keepalive timer is a special case, it's aim is to prevent timeouts, > > so triggering earlier rather than later is desired behavior. In a > > reported case the user had a 3600s keepalive timer for preventing firewall > > disconnects (on a 3650s interval). They observed keepalive timers coming > > in up to four minutes late, causing unexpected disconnects. > > > > This commit adds upper_bound_timeout() function that takes a relative > > timeout and adjusts it based on timer wheel granularity so that supplied > > value effectively becomes an upper bound for the timer. > > > > I think there is a problem with this approach. Please correct me, if I'm > wrong. The timer wheel index and level calculation depends on > timer_base::clk. The timeout/delta which is used for this calculation is > relative to timer_base::clk (delta = expires - base::clk). timer_base::clk > is not updated in sync with jiffies. It is forwarded before a new timer is > queued. It is possible, that timer_base::clk is behind jiffies after > forwarding because of a not yet expired timer. > > When calculating the level/index with a relative timeout, there is no > guarantee that the result is the same when actual enqueueing the timer with > expiry = jiffies + timeout . Yes, you are correct. This especially is a problem for timeouts placed just before LVL_START(x), which is a good chunk of cases. I don't think it is possible to get to timer_base clock without meddling with the hot-path. 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. -- Artem