Re: [PATCH] mm: PageLRU can be non-atomic bit operation

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

 



Hisashi Hifumi wrote:

At 22:42 07/04/23, Hugh Dickins wrote:
 >On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
 >> >No.  The PG_lru flag bit is just one bit amongst many others:
 >> >what of concurrent operations changing other bits in that same
 >> >unsigned long e.g. trying to lock the page by setting PG_locked?
 >> >There are some places where such micro-optimizations can be made
 >> >(typically while first allocating the page); but in general, no.
 >>
>> In i386 and x86_64, btsl is used to change page flag. In this case, if btsl
 >> without lock prefix
 >> set PG_locked and PG_lru flag concurrently, does only one operation
 >> succeed ?
 >
 >That's right: on an SMP machine, without the lock prefix, the operation
 >is no longer atomic: what's stored back may be missing the result of
 >one or the other of the racing operations.
 >

In the case that changing the same bit concurrently, lock prefix or other
spinlock is needed. But, I think that concurrent bit operation on different bits
is just like OR operation , so lock prefix is not needed.

AMD instruction manual says about bts that ,

"Copies a bit, specified by bit index in a register or 8-bit immediate value (second operand), from a bit string (first operand), also called the bit base, to the carry flag (CF) of the rFLAGS register, and then
sets the bit in the bit string to 1."

BTS instruction is read-modify-write instruction on bit unit. So concurrent bit operation on different
bits may be possible.


No matter what actual instruction is used, the SetPageLRU operation (ie.
without the double underscore prefix) must be atomic, and the __SetPageLRU
operation *can* be non-atomic if that would be faster.

As Hugh points out, we must have atomic ops here, so changing the generic
code to use the __ version is wrong. However if there is a faster way that
i386 can perform the atomic variant, then doing so will speed up the generic
code without breaking other architectures.

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux