Re: clear_bit_unlock_is_negative_byte

[Brad Boyer <flar@allandria.com>]

On Fri, Jul 21, 2023 at 12:59:48PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 21, 2023 at 08:34:55AM +0200, Andreas Schwab wrote:
> > Why are you using XOR if you want to clear a bit?  If it operates on a
> > byte, why does it receive a pointer to long?
> 
> It's a clever hack.  This function has exactly one user, and it's an
> important one -- folio_unlock().  Bit 7 is set if there are other
> threads waiting for this folio to be unlocked.  There are two reasonable
> implementations, depending what kind of CPU you have; you can either
> load-locked; clear the bottom bit, store-conditional, test bit 7.  Or
> x86 and m68k have the perfect instruction to clear a bit and set the
> Negative flag if bit 7 is set.
> 
> As I said in the earlier email, BCLR doesn't affect the N flag, but
> EORI and ANDI do.  We are guaranteed that the bit we're clearing is set,
> so EORI will work.  ANDI would also work.

There shouldn't be any performance difference between using eori.b and
andi.b, since the compiler would fully generate the immediate mask
value either way. Wouldn't readability suggest that we should use the
AND operation to make it more obvious what the code is doing and make
it more consistent with the other implementations of this function?

	Brad Boyer
	flar@allandria.com