From: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: test_and_set_bit implementation
Date: Wed, 13 Dec 2006 10:02:48 +0000 [thread overview]
Message-ID: <457FCFC8.40709@bull.net> (raw)
In-Reply-To: <457EC42C.90002@bull.net>
Matthew Wilcox wrote:
> The original code and your rewrite both access memory twice in the loop.
> Why don't we do it with one memory reference per loop instead?
>
> {
> CMPXCHG_BUGCHECK_DECL
>
> u32 *m = (u32 *)addr + (nr >> 5);
> u32 bit = 1 << (nr & 31);
>
> u32 old = *m;
> while (!(old & bit)) {
> u32 new = old | bit;
> u32 prev = cmpxchg_acq(m, old, new);
> CMPXCHG_BUGCHECK(m);
> if (prev = old)
> return 1;
> old = prev;
> }
>
> return 0;
> }
>
> Looking at the disassembly of grab_block() in fs/ext2/balloc.c, I don't
> see much difference. The ld4.acq turns into a regular ld4 (because
> 'm' is no longer tagged as volatile), and is hoisted out of the loop.
> Interestingly, gcc chooses to reorder the tests, and make the loop four
> bundles long instead of three, but will 'goto repeat' in two bundles
> instead of four. Using likely()/unlikely() doesn't persuade gcc to
> change the order of the two branches, so I assume it actually is better
> to do it this way.
I like this code with the following slight modifications:
- let's keep "m" as pointer to volatile
- let's keep on using "__u32" types
- not sure we need "new"
- return the old bit
volatile __u32 *m = (volatile __u32 *)addr + (nr >> 5);
__u32 bit = 1 << (nr & 31);
__u32 old = *m;
while (!(old & bit)) {
__u32 prev = cmpxchg_acq(m, old, old | bit);
CMPXCHG_BUGCHECK(m);
if (prev = old)
return 0;
old = prev;
}
return 1;
It compiles to:
0: and r151,r32
6: mov r14=1
c: extr r32=r32,5,27;;
10: shladd r18=r32,2,r33;;
16: ld4.acq r16=[r18]
1c: shl r17=r14,r15;;
20: and r14=r17,r16;;
26: nop.m 0x0
2c: cmp4.eq p7,p6=0,r14
30: nop.b 0x0
36: nop.b 0x0
3c: (p06) br.cond.dpnt.few a0 <+0xa0>
40: nop.m 0x0
46: zxt4 r14=r16
4c: nop.b 0x0;;
50: mov.m ar.ccv=r14;;
56: nop.m 0x0
5c: or r14=r17,r16
60: nop.m 0x0;;
66: cmpxchg4.acq r14=[r18],r14,ar.ccv
6c: nop.i 0x0;;
70: cmp4.eq p7,p6=r14,r16
76: nop.f 0x0
7c: and r15=r17,r14
80: mov r16=r14
86: nop.f 0x0
8c: (p07) br.cond.dpnt.few b0 <+0xb0>;;
90: nop.m 0x0
96: cmp4.eq p7,p6=0,r15
9c: (p07) br.cond.dptk.few 40 <+0x40>
a0: nop.m 0x0
a6: mov r8=1
ac: br.ret.sptk.many b0;;
b0: nop.m 0x0
b6: mov r8=r0
bc: br.ret.sptk.many b0;;
It seems to be o.k., thanks.
Zoltán Menyhárt
next prev parent reply other threads:[~2006-12-13 10:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-12 15:01 test_and_set_bit implementation Zoltan Menyhart
2006-12-12 15:47 ` Matthew Wilcox
2006-12-12 17:20 ` Christoph Lameter
2006-12-12 17:22 ` Christoph Lameter
2006-12-12 18:07 ` Matthew Wilcox
2006-12-13 10:02 ` Zoltan Menyhart [this message]
2006-12-13 10:20 ` Zoltan Menyhart
2006-12-13 12:29 ` Matthew Wilcox
2006-12-13 18:28 ` Christoph Lameter
2006-12-14 9:24 ` Zoltan Menyhart
2006-12-14 9:37 ` Zoltan Menyhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=457FCFC8.40709@bull.net \
--to=zoltan.menyhart@bull.net \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.