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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5E5EC433ED for ; Wed, 21 Apr 2021 14:08:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 98AFA61453 for ; Wed, 21 Apr 2021 14:08:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236202AbhDUOJ1 (ORCPT ); Wed, 21 Apr 2021 10:09:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239452AbhDUOJF (ORCPT ); Wed, 21 Apr 2021 10:09:05 -0400 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CF60C06174A for ; Wed, 21 Apr 2021 07:08:32 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id b10so42172428iot.4 for ; Wed, 21 Apr 2021 07:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l1mA+bXgMyEnqSc8k5VDUxU2oNU/RLd1zwL6lAl3pUs=; b=Ecvgf6QOWXhpql5sQ06Tb01lKwQHpKDgjBv6g74QnS9/yfponh28l9ibY3hUVYpxM6 A3lsEIqkk0soZNl444tuBLa1T8sbfggeE7yrlHrPXWX2TrKEitBGDbztvqTmkKAkQ8zu 0VKiL3n/SBR6YU+NH9mN+HqZ0uYcvchmYkk0YEeeNFw/a/ZWYc3bW9rjyLwIjL4LYuF7 py2b52kTyvU/rnIgi8z4WnQ8E8MJiAKj5rfLcnLwkpSolBpKgvWt4vqhg/auFyX2USLQ MADtTErvDu8IUmx/hwPRBoIuWIC8sSrn6M9r0DoBR90xDxvMZveeSzInliOHPXjy2oho EnlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l1mA+bXgMyEnqSc8k5VDUxU2oNU/RLd1zwL6lAl3pUs=; b=e3UJGbNH9leLA5XaU1kMsCSpKPg77gZLWmhqzR7aTYboQ4TGhaLD2NujIQtOld7lOh zGDlOhUiL7vDO5utw9nATGNhv58tLjdPB1BUiqXNI0CAumXrGDvcwc2/AnJbTa4HUCPh L+18sA5mZEV4fE1f6IZ59c80S6hKEzWxPptRtwmHDQyqYN4hojRULFh8ed4ew+/aBEA9 vr9+ETWCIQtuG4ktvjBeA1EDFxoPMfc8XDsHtNKhY2XePAi9rSK6eOhJG3xJ/3kIYhcz 70hH3z/ZFqtvwImc+pz7qWvFCL5ozUV3IPkurIYGBUYTTfXZgekDmAtzV1dhJ2PWYKT5 KltA== X-Gm-Message-State: AOAM533bzIxZ53NQ9hYbA6eFAJCYP1Uz72twmsIcL1btRKCL7BVXhwnT YrYI456TnWe5d6hmp8RKWd+mkhk5KDneecraRRMD/Q== X-Google-Smtp-Source: ABdhPJwJpPv9j37+hi4F3tGlbqa7selR5RrQee/T40hK2bnb85oifvozkgf99HuZSMABBVcwXhuKmyc97oiw5Z0ekzI= X-Received: by 2002:a02:918d:: with SMTP id p13mr26420892jag.51.1619014111274; Wed, 21 Apr 2021 07:08:31 -0700 (PDT) MIME-Version: 1.0 References: <87r1jbv6jc.ffs@nanos.tec.linutronix.de> <87eef5qbrx.ffs@nanos.tec.linutronix.de> In-Reply-To: <87eef5qbrx.ffs@nanos.tec.linutronix.de> From: Lorenzo Colitti Date: Wed, 21 Apr 2021 23:08:19 +0900 Message-ID: Subject: Re: [PATCH] hrtimer: Update softirq_expires_next correctly after __hrtimer_get_next_event() To: Thomas Gleixner Cc: Greg KH , =?UTF-8?Q?Maciej_=C5=BBenczykowski?= , Ingo Molnar , Anna-Maria Behnsen , lkml , mikael.beckius@windriver.com, =?UTF-8?Q?Maciej_=C5=BBenczykowski?= , Will Deacon Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 11:19 PM Thomas Gleixner wrote: > 1) hrtimer is contrary to timer_list not really suited for high > frequency start/cancel/start/... cycles of a timer. It's optimized > for the start and expire precisely case. Ack. This is not what the f_ncm gadget code needs. It just needs a timer to fire "about 300us after the last packet submitted". Under load the timer will almost never fire since there will always be another packet coming. So the speed of adding/updating the timer is much more important than the accuracy. We will try to move it to timer_list. > I assume that's an ARM64 system. ARM64 CPUs have an architected per > CPU timer where the reprogramming is pretty fast as it's next to > the CPU, but who knows what your system is using. This system appears to be using timer hardware that is... slow to program (microseconds). We're looking at whether it's possible to use the arch timer instead. > Now in the meantime I looked into __hrtimer_start_range_ns() whether > that double reprogram can be avoided without creating a total trainwreck > and imposing penalty on all sensible use cases. Completely untested > patch below should do the trick and it's not ugly enough that I hate it > with a passion. I tested this and in my simple benchmark, the double calls are gone and hrtimer_start calls tick_program_event approximately once (more precisely, 90.06% of the time; sometimes it doesn't call it at all). This is not enough to cancel the regression we're seeing because the previous code would pretty much never call tick_program_event at all. But it's definitely better.