From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DE5333B29D for ; Mon, 6 Jan 2020 10:54:14 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578326054; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6pr2vDp7GuUB/s0xuB/d+Xhxr3Bho+yffIoUy9cSlWQ=; b=CqCrVLMQwIXuBd2pcYqgbsdnfZkZFOtlZ45SU41Fy5fezW0Olh9+Rea94lUJADcE+D22Gd wAmmruq/4jwOvZY2UNV4/3II7PKh3R/PNjPjXzX4dPPUa5kBF6N80VywRLiSlZwPQhqKsN mKL5b7qYEDLAiLWPyVosA3lqevJwqco= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-PHHmnaxdO5WqQUlcmoUG9g-1; Mon, 06 Jan 2020 10:54:13 -0500 Received: by mail-wm1-f71.google.com with SMTP id n17so1433368wmk.1 for ; Mon, 06 Jan 2020 07:54:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=6pr2vDp7GuUB/s0xuB/d+Xhxr3Bho+yffIoUy9cSlWQ=; b=awbSgb7at7fdB3jb5W/eliBHD8aX+Lj7AiBLFLYfVCcuNsu2VJsmqkEXX99fN3+wu5 G7GfcFO9HUMEEswN4MU1/53n3zF3X8UgRUF70UNMWogFRQ16VJ8H+XSsNwHEECSwenUk dHTo471wYEv/KKnU19QdcK0YPoDMECpitI697HIFBEFN1xXWzwIADC2a6p223W5kEThQ O9x/vwBuRYQaOD5eUDg0ozGLUgtTa03Vv6MJD/LB/8JS4nh3lz5b/t4UfYNOWCnnQoSg iVcBroHYoWdFCN7I882VTIJZQyPzms1O8gfh8dn5ETV6Vhxxyz2z2PfhbC9cVTOEIf6M fqRQ== X-Gm-Message-State: APjAAAVKGoLdYMiiRV5homgueK+r+IkFSeRP1ZuoIx+PMgPjYsGCMbN3 YLF1LcvFw/vdTbeb87KRpm4n2jgw9IJcyGZyfuFZcSCPPyAQV5DUKAmIX+WXFa4ymxpMmhh2Um3 8QfYzi2m57379N3MiN6QG/F9FqN4A0kTilkw= X-Received: by 2002:adf:db84:: with SMTP id u4mr106058102wri.317.1578326052153; Mon, 06 Jan 2020 07:54:12 -0800 (PST) X-Google-Smtp-Source: APXvYqyYHtUInFoiYX9T3XvsmrAcd5xwxCOKNazEwOVw9Q1lBVna6NJ3ZvtZ8RfME1lAJFCx2BX/iA== X-Received: by 2002:adf:db84:: with SMTP id u4mr106058082wri.317.1578326051996; Mon, 06 Jan 2020 07:54:11 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id x6sm23375389wmi.44.2020.01.06.07.54.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2020 07:54:11 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id D742B180ADA; Mon, 6 Jan 2020 16:54:10 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: John Yates Cc: Johannes Berg , linux-wireless , Kan Yan , Make-Wifi-fast , Yibo Zhao , Rajkumar Manoharan , Felix Fietkau In-Reply-To: References: <20191222172423.131033-1-toke@redhat.com> <5bab549a72d526f4fd0f708f14b49a7af6e2c0b9.camel@sipsolutions.net> <87r20ck3x9.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 06 Jan 2020 16:54:10 +0100 Message-ID: <87mub0k2cd.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: PHHmnaxdO5WqQUlcmoUG9g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v5] mac80211: Switch to a virtual time-based airtime scheduler X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 15:54:15 -0000 John Yates writes: > On Mon, Jan 6, 2020 at 10:20 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> Or do a middle ground thing where we use 32-bit arithmetic >> for the per-station weights, but go to 64-bit for the weight sum? I >> don't really have a good grip on how much of a performance impact we're >> talking about here, so I'm not sure which I prefer... > > Double width accumulation is very common in many applications. > Double width addition and comparison are _much_ cheaper than > double width multiplication and division. Yeah, we'd be doing the accumulation in 64bit values in any case; we're talking about mainly multiplication here (the whole point of the reciprocal stuff is to get the division out of the fast path). So how big of an impact is one (or two) extra 64-bit multiplications going to have on a 32bit platform? -Toke