Re: clear_bit_unlock_is_negative_byte

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

 



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@xxxxxxxxxxxxx




[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux