> 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
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
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 doesn't
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
> 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
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.
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
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 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
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. trying to lock the
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 that
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
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
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
>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
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
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
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
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
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:
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
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
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.
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
26 matches
Mail list logo
