Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 31 May 2023 12:35:56 +0300 (EEST)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     "Shaopeng Tan (Fujitsu)" <tan.shaopeng@fujitsu.com>
cc:     "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        Reinette Chatre <reinette.chatre@intel.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Shuah Khan <shuah@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 17/24] selftests/resctrl: Replace count_bits with
 count_consecutive_bits()
In-Reply-To: <OSZPR01MB6328A57213FA4E13C21F91D18B489@OSZPR01MB6328.jpnprd01.prod.outlook.com>
Message-ID: <9043c594-68c2-b73e-2bad-c2506f206259@linux.intel.com>
References: <20230418114506.46788-1-ilpo.jarvinen@linux.intel.com> <20230418114506.46788-18-ilpo.jarvinen@linux.intel.com> <OSZPR01MB6328A57213FA4E13C21F91D18B489@OSZPR01MB6328.jpnprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-423328003-1685525760=:5379"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-423328003-1685525760=:5379
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT

On Wed, 31 May 2023, Shaopeng Tan (Fujitsu) wrote:

> Hi Ilpo,
> 
> > CAT and CMT tests depends on masks being continuous.
> > 
> > Replace count_bits with more appropriate variant that counts consecutive bits.
> > 
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > ---

> > @@ -218,6 +220,34 @@ static int get_bit_mask(char *filename, unsigned long
> > *mask)
> >  	return 0;
> >  }
> > 
> > +/*
> > + * count_consecutive_bits - Returns the longest train of bits in a bit mask
> > + * @val		A bit mask
> > + * @start	The location of the least-significant bit of the longest train
> > + *
> > + * Return:	The length of the consecutive bits in the longest train of bits
> > + */
> > +unsigned int count_consecutive_bits(unsigned long val, unsigned int
> > +*start) {
> > +	unsigned long last_val;
> > +	int count = 0;
> > +
> > +	while (val) {
> > +		last_val = val;
> > +		val &= (val >> 1);
> > +		count++;
> > +	}
> 
> There may not be a case that the most-significant bit is 1 at present, 
> but if this case exists, it cannot count correctly.

Can you please rephrase what is your concern here please?

I test 0U, 1U, ~0U, and a few more complex combinations of bits, and all 
returned correct count so I might not have understood what case you meant 
with your description.

This function does not count nor calculate the most-significant bit in
any phase but the longest train of bits using the count variable (and the 
least-significant bit of the longest train in the code that is not 
included into this partial snippet).

-- 
 i.

--8323329-423328003-1685525760=:5379--