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

[Nick Piggin <nickpiggin@yahoo.com.au>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/