lkml.org 
[lkml]   [2007]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: PageLRU can be non-atomic bit operation
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/

\
 
 \ /
  Last update: 2007-04-24 04:51    [W:0.098 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site