> This seems to imply that we need the lock prefix even when updating
> different bits within the same long (not just the same byte). Is this
> interpretation correct?
Yes, that is what I said. The consistency applies to loads/stores
(so e.g. for 128bit SSE2 load/stores too), not bytes.
The curr
On Tue, 2007-04-24 at 16:22 +0200, Andi Kleen wrote:
> > Why would you need any kind of lock when just changing a single bit,
> > if it didn't affect other bits of the same word? Just as you don't
> > need a lock when simply assigning a word, setting a bit to 0 or 1
> > is simple in itself (it doe
> Why would you need any kind of lock when just changing a single bit,
> if it didn't affect other bits of the same word? Just as you don't
> need a lock when simply assigning a word, setting a bit to 0 or 1
> is simple in itself (it doesn't matter if it was 0 or 1 before).
>
> > But, I think th
On Tue, 24 Apr 2007, 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. tryi
Hisashi Hifumi wrote:
At 11:47 07/04/24, Nick Piggin wrote:
>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
At 11:47 07/04/24, Nick Piggin wrote:
>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
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 sett
On Tue, 24 Apr 2007 10:54:27 +0900
Hisashi Hifumi <[EMAIL PROTECTED]> wrote:
> 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.
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 ar
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 c
>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
On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
>
> PageLRU flag operation is protected by zone->lru_lock, so
> SetPageLRU/ClearPageLRU
> can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation.
No. The PG_lru flag bit is just one bit amongst many others:
what of concurrent operations
Hi
PageLRU flag operation is protected by zone->lru_lock, so
SetPageLRU/ClearPageLRU
can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.21-rc7.org/include/linux/page-flags.h
linux-2.6.21-rc7/
13 matches
Mail list logo
