Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I thought we long long since removed the volatiles.
They're certainly still there in i386 and x86_64.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[ Restricting discussion to the i386 bitops implementation. ]
Hi Nick,
On 7/23/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi,
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> >
> > On Fri, 20 Jul 2007, Nick Piggin wrote:
> >
> >>So you did. Then to answer that,
Hi,
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Linus Torvalds wrote:
>
> On Fri, 20 Jul 2007, Nick Piggin wrote:
>
>>So you did. Then to answer that, yes it could be faster because there are
>>stupid volatiles sprinkled all over the bitops code so you could easily
>>end up having to do
Linus Torvalds wrote:
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be faster because there are
stupid volatiles sprinkled all over the bitops code so you could easily
end up having to do more loads. Does it make a real difference? Unlikely,
but David
Linus Torvalds wrote:
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be faster because there are
stupid volatiles sprinkled all over the bitops code so you could easily
end up having to do more loads. Does it make a real difference? Unlikely,
but David
Hi,
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be faster because there are
stupid volatiles sprinkled all over the bitops code so you could easily
end up having to do more loads.
Linus Torvalds [EMAIL PROTECTED] wrote:
I thought we long long since removed the volatiles.
They're certainly still there in i386 and x86_64.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[ Restricting discussion to the i386 bitops implementation. ]
Hi Nick,
On 7/23/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi,
On 7/23/07, Nick Piggin [EMAIL PROTECTED] wrote:
Linus Torvalds wrote:
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be
On Fri, 20 Jul 2007, Nick Piggin wrote:
>
> So you did. Then to answer that, yes it could be faster because there are
> stupid volatiles sprinkled all over the bitops code so you could easily
> end up having to do more loads. Does it make a real difference? Unlikely,
> but David loves counting
Andrew Morton wrote:
On Wed, 18 Jul 2007 15:56:53 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
+ if (type == AFS_LOCK_READ &&
+ vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
Andrew Morton wrote:
On Wed, 18 Jul 2007 15:56:53 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells [EMAIL PROTECTED] wrote:
+ if (type == AFS_LOCK_READ
+ vnode-flags (1 AFS_VNODE_READLOCKED)) {
Here we
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be faster because there are
stupid volatiles sprinkled all over the bitops code so you could easily
end up having to do more loads. Does it make a real difference? Unlikely,
but David loves counting
On Wed, 18 Jul 2007 15:56:53 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Tue, 17 Jul 2007 13:47:32 +0100
> > David Howells <[EMAIL PROTECTED]> wrote:
> >
> >
> >>+ if (type == AFS_LOCK_READ &&
> >>+ vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
> >
> >
>
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
+ if (type == AFS_LOCK_READ &&
+ vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
Here we use
vnode->flags & (1 << foo)
+ set_bit(AFS_VNODE_LOCKING,
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells [EMAIL PROTECTED] wrote:
+ if (type == AFS_LOCK_READ
+ vnode-flags (1 AFS_VNODE_READLOCKED)) {
Here we use
vnode-flags (1 foo)
+ set_bit(AFS_VNODE_LOCKING, vnode-flags);
On Wed, 18 Jul 2007 15:56:53 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells [EMAIL PROTECTED] wrote:
+ if (type == AFS_LOCK_READ
+ vnode-flags (1 AFS_VNODE_READLOCKED)) {
Here we use
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Here we use
>
> vnode->flags & (1 << foo)
>
> > + set_bit(AFS_VNODE_LOCKING, >flags);
>
> and elsewhere we use set_bit(foo, >flags) and clear_bit()
Ah... IIRC I was originally testing multiple bits in one go (test_bit()'s do
not
Andrew Morton [EMAIL PROTECTED] wrote:
Here we use
vnode-flags (1 foo)
+ set_bit(AFS_VNODE_LOCKING, vnode-flags);
and elsewhere we use set_bit(foo, vnode-flags) and clear_bit()
Ah... IIRC I was originally testing multiple bits in one go (test_bit()'s do
not merge
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> + if (type == AFS_LOCK_READ &&
> + vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
Here we use
vnode->flags & (1 << foo)
> + set_bit(AFS_VNODE_LOCKING, >flags);
and elsewhere we use
Fix file locking for AFS:
(*) Start the lock manager thread under a mutex to avoid a race.
(*) Made the locking non-fair: New readlocks will jump pending writelocks if
there's a readlock currently granted on a file. This makes the behaviour
similar to Linux's VFS locking.
Fix file locking for AFS:
(*) Start the lock manager thread under a mutex to avoid a race.
(*) Made the locking non-fair: New readlocks will jump pending writelocks if
there's a readlock currently granted on a file. This makes the behaviour
similar to Linux's VFS locking.
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells [EMAIL PROTECTED] wrote:
+ if (type == AFS_LOCK_READ
+ vnode-flags (1 AFS_VNODE_READLOCKED)) {
Here we use
vnode-flags (1 foo)
+ set_bit(AFS_VNODE_LOCKING, vnode-flags);
and elsewhere we use set_bit(foo,
22 matches
Mail list logo
