From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Tom Musta <tommusta@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
Scott Wood <scottwood@freescale.com>, Torsten Duwe <duwe@lst.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2] powerpc ticket locks
Date: Tue, 11 Feb 2014 14:38:35 +1100 [thread overview]
Message-ID: <1392089915.3996.60.camel@pasglop> (raw)
In-Reply-To: <20140211025645.GJ18016@ZenIV.linux.org.uk>
On Tue, 2014-02-11 at 02:56 +0000, Al Viro wrote:
> > So the question is, is it reasonable to have the ref smaller than
> > 32-bit...
>
> Every time you open a file, you bump dentry refcount. Something like
> libc or ld.so will be opened on just about every execve(), so I'd say
> that 16 bits is far too low. If nothing else, 32 bits might be too
> low on 64bit boxen...
So back to square 1 ... we can't implement together lockref, ticket
locks, and our lock confer mechanism within 64-bit.
I see two options at this stage. Both require a custom implementation
of lockref for powerpc, so some ifdef's such that we can replace the
generic implementation completely.
- We can use a small ref, and when it's too big, overflow into a larger
one, falling back to the "old style" lock + ref (an overflow bit or a
compare with ffff)
- We can have lockref "build" it's own lock out of the ticketpair and
ref, keeping the owner in a separate word. The owner doesn't strictly
need to be atomic.
Both are gross though :(
Anybody has a better idea ?
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Torsten Duwe <duwe@lst.de>, Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Scott Wood <scottwood@freescale.com>,
Tom Musta <tommusta@gmail.com>, Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] powerpc ticket locks
Date: Tue, 11 Feb 2014 14:38:35 +1100 [thread overview]
Message-ID: <1392089915.3996.60.camel@pasglop> (raw)
In-Reply-To: <20140211025645.GJ18016@ZenIV.linux.org.uk>
On Tue, 2014-02-11 at 02:56 +0000, Al Viro wrote:
> > So the question is, is it reasonable to have the ref smaller than
> > 32-bit...
>
> Every time you open a file, you bump dentry refcount. Something like
> libc or ld.so will be opened on just about every execve(), so I'd say
> that 16 bits is far too low. If nothing else, 32 bits might be too
> low on 64bit boxen...
So back to square 1 ... we can't implement together lockref, ticket
locks, and our lock confer mechanism within 64-bit.
I see two options at this stage. Both require a custom implementation
of lockref for powerpc, so some ifdef's such that we can replace the
generic implementation completely.
- We can use a small ref, and when it's too big, overflow into a larger
one, falling back to the "old style" lock + ref (an overflow bit or a
compare with ffff)
- We can have lockref "build" it's own lock out of the ticketpair and
ref, keeping the owner in a separate word. The owner doesn't strictly
need to be atomic.
Both are gross though :(
Anybody has a better idea ?
Ben.
next prev parent reply other threads:[~2014-02-11 3:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-07 16:58 [PATCH v2] powerpc ticket locks Torsten Duwe
2014-02-07 16:58 ` Torsten Duwe
2014-02-07 17:12 ` Peter Zijlstra
2014-02-07 17:12 ` Peter Zijlstra
2014-02-07 17:55 ` Torsten Duwe
2014-02-07 17:55 ` Torsten Duwe
2014-02-10 3:10 ` Benjamin Herrenschmidt
2014-02-10 3:10 ` Benjamin Herrenschmidt
2014-02-10 15:52 ` Torsten Duwe
2014-02-10 15:52 ` Torsten Duwe
2014-02-10 17:53 ` Peter Zijlstra
2014-02-10 17:53 ` Peter Zijlstra
2014-02-11 2:44 ` Benjamin Herrenschmidt
2014-02-11 2:44 ` Benjamin Herrenschmidt
2014-02-11 2:56 ` Al Viro
2014-02-11 2:56 ` Al Viro
2014-02-11 3:38 ` Benjamin Herrenschmidt [this message]
2014-02-11 3:38 ` Benjamin Herrenschmidt
2014-02-11 9:53 ` Raghavendra KT
2014-02-11 9:53 ` Raghavendra KT
2014-02-11 10:40 ` Torsten Duwe
2014-02-11 10:40 ` Torsten Duwe
2014-02-11 18:30 ` Scott Wood
2014-02-11 18:30 ` Scott Wood
2014-02-11 19:34 ` Benjamin Herrenschmidt
2014-02-11 19:34 ` Benjamin Herrenschmidt
2014-02-11 9:39 ` Raghavendra KT
2014-02-11 9:39 ` Raghavendra KT
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=1392089915.3996.60.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=anton@samba.org \
--cc=duwe@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=scottwood@freescale.com \
--cc=tommusta@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.