From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Lameter <cl@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: [x86] Unify semaphore_32.S and rwlock_64.S
Date: Wed, 20 Jan 2010 16:55:42 -0800 [thread overview]
Message-ID: <4B57A60E.5030306@zytor.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1001201637320.13231@localhost.localdomain>
On 01/20/2010 04:46 PM, Linus Torvalds wrote:
>
>
> On Wed, 20 Jan 2010, Linus Torvalds wrote:
>>
>> #define RWSEM_UNLOCKED_VALUE 0x00000000
>> #define RWSEM_ACTIVE_BIAS 0x00000001
>> #define RWSEM_ACTIVE_MASK 0x3fffffff
>> #define RWSEM_WAITING_BIAS (~RWSEM_ACTIVE_MASK)
>> #define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
>> #define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
>
> Btw, doing that RWSEM_WAITING_BIAS cleanup (we currently have it as an
> independent constant) means that now all constants are shared except for
> that RWSEM_ACTIVE_MASK. So it ends up being something like this:
>
> #ifdef CONFIG_RWSEM_64bit
> typedef __s64 rwsem_count_t;
> #define RWSEM_ACTIVE_MASK 0x3fffffff
> #else
> typedef __s32 rwsem_count_t;
> #define RWSEM_ACTIVE_MASK 0xffff
> #endif
>
> #define RWSEM_UNLOCKED_VALUE 0x00000000
> #define RWSEM_ACTIVE_BIAS 0x00000001
> #define RWSEM_WAITING_BIAS (~RWSEM_ACTIVE_MASK)
> #define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
> #define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
>
> with just that two-line difference for the 32-bit/64-bit case.
>
> At least I _think_ so.
>
Yes, I already had that change in my tree (or rather, I wrote it as
(-RWSEM_ACTIVE_MASK-1) to be consistent with what was previously there,
but (~RWSEM_ACTIVE_MASK) makes more sense.)
> And it's worth noting (again) that I didn't actually push the
> twsem_count_t changes down into the slow-path code in lib/rwsem.c. There's
> a few variables there that might need looking at too. I _think_ they are
> all ok as-is (unlike the header file, lib/rwsem.c seems to consistently
> use 'signed long' rather than mix 32-bit and 64-bit types), but it migh be
> cleaner to make them rwsem_count_t's too.
Yes, if we have it we should it consistently.
-hpa
next prev parent reply other threads:[~2010-01-21 0:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 22:21 [x86] Unify semaphore_32.S and rwlock_64.S Christoph Lameter
2010-01-19 22:30 ` H. Peter Anvin
2010-01-20 19:49 ` Christoph Lameter
2010-01-20 20:14 ` H. Peter Anvin
2010-01-20 20:51 ` Christoph Lameter
2010-01-20 23:57 ` Linus Torvalds
2010-01-21 0:02 ` H. Peter Anvin
2010-01-21 6:28 ` H. Peter Anvin
2010-01-21 0:46 ` Linus Torvalds
2010-01-21 0:55 ` H. Peter Anvin [this message]
2010-01-20 23:46 ` Linus Torvalds
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=4B57A60E.5030306@zytor.com \
--to=hpa@zytor.com \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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.