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 045B3C7618E for ; Fri, 21 Apr 2023 14:40:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232903AbjDUOkO (ORCPT ); Fri, 21 Apr 2023 10:40:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46608 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233059AbjDUOjq (ORCPT ); Fri, 21 Apr 2023 10:39:46 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1FF8415616 for ; Fri, 21 Apr 2023 07:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sipsolutions.net; s=mail; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-To: Resent-Cc:Resent-Message-ID; bh=C4gj1rdsY5Z6p5jNGYbkOqRjPl5OXVGY3dVpTyv0MvY=; t=1682087896; x=1683297496; b=WuB/ZryuPajYmZndafaa0O7NM24H/Mqy8nlhhh+Ay8fqhte QUBi5tI56J1cq4ARlrErv06canUMd8flD9kKPrKjzsKI6Qs8d0HO7d0EkPo6h9mxEM7sMgpJP2nhz R935UlqEYL0e8WKd2sWhWDhQkQox4zjVLsb1zjgy0RpduqTx62KRbbZ6Fs3XSryL1sO+F3s2s0Zxa tCFFTwCrdCoaqZSqJ7Jrk6zNYpuWAElH/h3O7iclTgjwCeaeJ8mqd86djUrel6TM75WM3fPxnYt7N dzIoGaTjKREYRYBInAqL7ByKu4nXVQBN+tH+RW1ccc2m8+fuAuuGQSi8Hmxv53YQ==; Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1pprtg-004TZl-0b; Fri, 21 Apr 2023 16:38:00 +0200 Message-ID: <3f505aba559d4ce068ef6d2fd7743045e0d93b9f.camel@sipsolutions.net> Subject: Re: [RFC v2] average: rewrite for clearity From: Johannes Berg To: Benjamin Beichler , nbd@nbd.name, linux-wireless@vger.kernel.org Date: Fri, 21 Apr 2023 16:37:59 +0200 In-Reply-To: <20230421134604.211128-1-benjamin.beichler@uni-rostock.de> References: <20230421134604.211128-1-benjamin.beichler@uni-rostock.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Fri, 2023-04-21 at 13:46 +0000, Benjamin Beichler wrote: > Move the former *_add function with its implicit initialization into a > separate function, when the user explicitly wants to init with the first > added value, although this creates issues, when 0 is a expected value for > the internal value. >=20 > Add a separate init function with value parameter to allow init with > distinct value, which was formerly done by the implicit init of old > *_add function. >=20 Sure, this is what you said :-) I still don't really think it's feasible. First, this breaks all the users, because if you have e.g. virtio's DECLARE_EWMA(pkt_len, 0, 64) then it will take a long time to get away from 0. So then we could say we'll just fix them, but what value actually makes sense to init with? You don't necessarily know, right? Initially biasing towards the first value makes a lot more sense than initially biasing towards zero, no? And then if you want to achieve that, now you have to either use _add_or_init(), which is probably what people will do, but that continues having the problem ... I don't really see how this is a net improvement - we'd still have to fix the individual users with it, e.g. maybe the mesh case that started this investigation could bias towards success (init with 100) and then use _add() rather than _add_or_init(), but then again we're back to having to make individual choices with the users. I don't really see how that's better than fixing it for real with the existing behaviour of biasing towards the first value? johannes