From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E2BFC433EF for ; Sat, 2 Apr 2022 06:55:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238366AbiDBG5k (ORCPT ); Sat, 2 Apr 2022 02:57:40 -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 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