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=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 BDD1DC43381 for ; Thu, 28 Feb 2019 10:09:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 96D9E2183F for ; Thu, 28 Feb 2019 10:09:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732298AbfB1KJw convert rfc822-to-8bit (ORCPT ); Thu, 28 Feb 2019 05:09:52 -0500 Received: from eu-smtp-delivery-151.mimecast.com ([207.82.80.151]:31696 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730388AbfB1KJw (ORCPT ); Thu, 28 Feb 2019 05:09:52 -0500 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-144-XJMeSsFyOUiqWfA44RT8TQ-1; Thu, 28 Feb 2019 10:09:49 +0000 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b::d117) by AcuMS.aculab.com (fd9f:af1c:a25b::d117) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 28 Feb 2019 10:10:33 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Thu, 28 Feb 2019 10:10:33 +0000 From: David Laight To: 'Leslie Monis' CC: "netdev@vger.kernel.org" Subject: RE: [PATCH net-next] net: sched: pie: fix 64-bit division Thread-Topic: [PATCH net-next] net: sched: pie: fix 64-bit division Thread-Index: AQHUzjfw/QEeBPQQhkKavgHbwVOxNKXzazRQgABm0wCAASx6sA== Date: Thu, 28 Feb 2019 10:10:33 +0000 Message-ID: <387a2fe8539c4de7bf3f97aadbd9b924@AcuMS.aculab.com> References: <20190227010006.22219-1-lesliemonis@gmail.com> <44c1c447befd45e49a06b1e3d3f5f7a6@AcuMS.aculab.com> <20190227161228.GA2014@Inspiron-3521> In-Reply-To: <20190227161228.GA2014@Inspiron-3521> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: XJMeSsFyOUiqWfA44RT8TQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Leslie Monis > Sent: 27 February 2019 16:12 > > On Wed, Feb 27, 2019 at 10:11:14AM +0000, David Laight wrote: > > From: Leslie Monis > > > Sent: 27 February 2019 01:00 > > > Use div_u64() to resolve build failures on 32-bit platforms. > > > > > > Fixes: 3f7ae5f3dc52 ("net: sched: pie: add more cases to auto-tune alpha and beta") > > > Signed-off-by: Leslie Monis > > > --- > > > net/sched/sch_pie.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/net/sched/sch_pie.c b/net/sched/sch_pie.c > > > index 4c0670b6aec1..f93cfe034c72 100644 > > > --- a/net/sched/sch_pie.c > > > +++ b/net/sched/sch_pie.c > > > @@ -429,7 +429,7 @@ static void calculate_probability(struct Qdisc *sch) > > > */ > > > > > > if (qdelay == 0 && qdelay_old == 0 && update_prob) > > > - q->vars.prob = (q->vars.prob * 98) / 100; > > > + q->vars.prob = 98 * div_u64(q->vars.prob, 100); > > > > This has significantly different rounding after the change. > > The result for small values is very different. > > The alterative: > > q->vars.prob -= div_u64(q->vars.prob, 50); > > is much nearer to the original - but never goes to zero. > > > > If the 98% decay factor isn't critical then you could remove > > 1/64th or 1/32nd + 1/16th to avoid the slow division. > > > > David > > Hi David, > > You're right, the change does make the result for small > values different. I made it anyway as the probability > value is scaled by u64. It is safe to say that q->vars.prob > holds relatively large values (in its scaled form) in all > cases where it isn't 0. > > But, I think we can avoid the slow division here. RFC 8033 > does say that using (1 - 1/64) should be sufficient. This > will give us: > q-vars.prob -= q->vars.prob >> 6; > which I feel would be much better. What do you reckon? I think I'd leave it as a division - the compiler should do the shift. So: /* Scale by 98.4% */ q-vars.prob -= q->vars.prob / 64u; David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)