[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/bitops: adjust partial first word handling in __find_next{,_zero}_bit()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Thu, 19 Feb 2026 17:05:34 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oSgHdUcv0+HF384iyma8R33+dhHWTJ8vI8YpkUR2HZE=; b=KT3+r2rjO9/FphbM4LOc2mWL0I8IkMPIvlyOoddrlXODD7BAU8jfuE6VU82bmMSqxmXyxi5ustIlDBY2VSLfj0k4UJNPq25Wi5qx87gd/hhMDxFhWSBKABHaQ5dS5XzdGzUlB2RRsLWwx5cK6HMBUev3r6QVe94F2h6de56wEzJlPqPWPbF4wtiUddZAU4LOWIqL/CaPqDOYnPSZTkSxqLAAAr+rnWVlNw7BcLykBje45YxRdhh6WeyUWZHMFGwlEuCIiwm+M6gqDfQW1Psf+JOpts8eS+h9kD8Yr/Jl6AbraWeUya4bxLgmgptLUT1MWCSPw+cxCxpnTYUaAml8QQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=McprM9qJ8KkcqEJzoFc4bFU4r0HMR/6Xi5zg4DhfznzBn7c/ffC4uejlUEhgYcU7ea2wSBv3c87518+S4B8Fo5yWib6GvlZ1A0aO9QrZowkWM+K31mdqMT01LlCJko2pQXkZjt2Gk3QNvAbCohRep/8U1Np+7k4vXQsDIE5v1BgVe19KL36LCTL+UxsI+yWFKSDqYhRZ6hwi415qqYqsWc4LBdiCAXvyIkTU5RsE+/gFh0pX216rjcLY4E3omJ9vk5O75d+SmM7cjYNdVTmW5Dfofn1jEiJLc0ohoCRWOTYDqhwYIxjt03Qtxm9y0k9gvk4ZT+WA1IzCQgQsfWNPmg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Thu, 19 Feb 2026 17:06:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 19/02/2026 3:42 pm, Jan Beulich wrote:
> There's no need to subtract "bit" in what is passed to __scanbit(), as the
> other bits are zero anyway after the shift (in __find_next_bit()) or can
> be made so (in __find_next_zero_bit()) by flipping negation and shift. (We
> actually leverage the same facts in find_next{,_zero}_bit() as well.) This
> way in __scanbit() the TZCNT alternative can be engaged.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

I agree that we're already doing that in find_next{,_zero}_bit() and
therefore ought to be safe here.

What's really confusing about all of this is that __scanbit() differs
from ffs() by wanting a return value in the range [1, 64).  With that in
mind, I think we can do exactly the same as we do in arch_ffs(), but
preloading with BITS_PER_LONG rather than -1.  That in turn removes the
alternative and simplifies things further.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.