Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1485794ybj; Fri, 8 May 2020 02:24:13 -0700 (PDT) X-Google-Smtp-Source: APiQypKskG2BwxdWZ/2e7ymzU3GT7U+E3r2TgGxOKK818sETQ8zHzOzgxhg9xhe30qnhHdk3gyiV X-Received: by 2002:a05:6402:30ad:: with SMTP id df13mr1314390edb.339.1588929853286; Fri, 08 May 2020 02:24:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588929853; cv=none; d=google.com; s=arc-20160816; b=mQiX71b+7YIwifG494bcwlJgGtAEbTNwusf6U2uwJlhyalbFHQuqSNqtNcDOxkPSFZ 9SJ/R/Xwn3zWijbHSku2RwoWd5to8u0xSaNDOBnJHjF9y7+/Ihv66GU7NNTvv7ct254z 7NBbSJ3pOWTLEKlvFfWpWiGzdnV7kizSQt/Mxxv8aIOv7BS/3QKoFHea/Nk3AyrRRjEN hlJzvDTUosQLqA5m31Ta3MaifBC7tiaj0nXZQsRqyO5wNQy2NdRxS88ljL3KgFZ24siR dTqO+Zi1e1jitdtn27HY3LDGVYcgxY11LxCWRp2Dw1qaws53Yyi7b8hJUxEf94kbbARQ p2eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=KJ1FlBZcbaKpYD/mOm6gbCrkdb4h+IdPlrhTYuw1Mgw=; b=PUB/ckPyuwFQYXSDv/dmTRCQ5MJsqhzg7nUk3q7S3RaJsNJu9lr0ehsKWc/sUvxxlG YymqRhnlLjfLhE7NfW0svRaf281HdTRGh6K0Z5cGWV/JCjTaNqSor5LtWufuhttww0dk d0T8e9Ea2rdGg9ksilCv5F+z6u/mk68hwc/cCq4I0dPXAVDzxMer6eYvtXmOslzEO+Um WPnnLwc/jYwDm4o1OQvcRdL/u/YLpqvZAp8gz9Zb7LDM27v0hDwB9M8i0uv0sSqLHCRt rcAVWaD9PoHPRcjgv1lWe7d4C/8Ad6mpekvnAJGCYdE4EibhvLA/WZRLaIxHeFcJOX5W sUaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qh10si642802ejb.49.2020.05.08.02.23.49; Fri, 08 May 2020 02:24:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726325AbgEHJUG (ORCPT + 99 others); Fri, 8 May 2020 05:20:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:34438 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725379AbgEHJUF (ORCPT ); Fri, 8 May 2020 05:20:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4FDBFB020; Fri, 8 May 2020 09:20:07 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 70DEF1E12A6; Fri, 8 May 2020 11:20:03 +0200 (CEST) Date: Fri, 8 May 2020 11:20:03 +0200 From: Jan Kara To: Andrew Morton Cc: Tan Hu , linux-kernel@vger.kernel.org, xue.zhihong@zte.com.cn, wang.yi59@zte.com.cn, wang.liang82@zte.com.cn, Jan Kara Subject: Re: [PATCH] lib/flex_proportions.c: aging counts when fraction smaller than max_frac/FPROP_FRAC_BASE Message-ID: <20200508092003.GC20446@quack2.suse.cz> References: <1588746088-38605-1-git-send-email-tan.hu@zte.com.cn> <20200507164614.4a816d2aa1b341be937b128a@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200507164614.4a816d2aa1b341be937b128a@linux-foundation.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for CC Andrew. On Thu 07-05-20 16:46:14, Andrew Morton wrote: > On Wed, 6 May 2020 14:21:28 +0800 Tan Hu wrote: > > > If the given type has fraction smaller than max_frac/FPROP_FRAC_BASE, > > __fprop_inc_percpu_max should follow the design formula and aging > > fraction too. > > > > Signed-off-by: Tan Hu > > --- > > lib/flex_proportions.c | 7 +++---- > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > diff --git a/lib/flex_proportions.c b/lib/flex_proportions.c > > index 7852bfff5..451543937 100644 > > --- a/lib/flex_proportions.c > > +++ b/lib/flex_proportions.c > > @@ -266,8 +266,7 @@ void __fprop_inc_percpu_max(struct fprop_global *p, > > if (numerator > > > (((u64)denominator) * max_frac) >> FPROP_FRAC_SHIFT) > > return; > > - } else > > - fprop_reflect_period_percpu(p, pl); > > - percpu_counter_add_batch(&pl->events, 1, PROP_BATCH); > > - percpu_counter_add(&p->events, 1); > > + } > > + > > + __fprop_inc_percpu(p, pl); So the code is actually correct as is because if max_frac < FPROP_FRAC_BASE, we call fprop_fraction_percpu() which calls fprop_reflect_period_percpu(). So the 'else' is there to avoid calling the function twice. That being said calling fprop_reflect_period_percpu() twice as we would with your patch does no big harm as we'd just quickly bail on pl->period == p->period test. So I think the code is easier to understand the way you suggest without significant downside. But please update the changelog to explain that this is just code cleanup (with the above reasoning) and not a functional fix. Honza -- Jan Kara SUSE Labs, CR