From: Nick Piggin <nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>
To: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>
Cc: "Luck, Tony" <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: down_spin() implementation
Date: Fri, 28 Mar 2008 11:01:24 +1100 [thread overview]
Message-ID: <200803281101.25037.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <20080327141508.GL16721-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
On Friday 28 March 2008 01:15, Matthew Wilcox wrote:
> On Wed, Mar 26, 2008 at 01:29:58PM -0700, Luck, Tony wrote:
> > This looks a lot cleaner than my ia64 specific code that
> > used cmpxchg() for the down() operation and fetchadd for
> > the up() ... using a brand new semaphore_spin data type.
>
> I did brifly consider creating a spinaphore data type, but it's
> significantly less code to create down_spin().
>
> > It appears to work ... I tried to do some timing comparisons
> > of this generic version against my arch specific one, but the
> > hackbench test case has a run to run variation of a factor of
> > three (from 1min9sec to 3min44sec) so it is hopeless to try
> > and see some small percentage difference.
>
> Thanks for testing and putting this together in patch form. I've fixed it
> up to address Jens' astute comment and added it to my semaphore patchset.
>
> http://git.kernel.org/?p=linux/kernel/git/willy/misc.git;a=shortlog;h=semap
>hore-20080327
>
> Stephen, I've updated the 'semaphore' tag to point ot the same place as
> semaphore-20080327, so please change your linux-next tree from pulling
> semaphore-20080314 to just pulling plain 'semaphore'. I'll use this
> method of tagging from now on.
>
> Here's the edited patch.
>
> commit 517df6fedc88af3f871cf827a62ef1a1a2073645
> Author: Matthew Wilcox <matthew-Ztpu424NOJ8@public.gmane.org>
> Date: Thu Mar 27 09:49:26 2008 -0400
>
> Add down_spin()
>
> ia64 would like to use a semaphore in flush_tlb_all() as it can have
> multiple tokens. Unfortunately, it's currently nested inside a
> spinlock, so they can't sleep. down_spin() is the cheapest solution to
> implement.
Uhm, how do you use this exactly? All other holders of this
semaphore must have preempt disabled and not sleep, right? (and
so you need a new down() that disables preempt too)
So the only difference between this and a spinlock I guess is
that waiters can sleep rather than spin on contention (except
this down_spin guy, which sleeps).
Oh, I see from the context of Tony's message... so this can *only*
be used when preempt is off, and *only* against other down_spin
lockers.
Bad idea to be hack this into the semaphore code, IMO. It would
take how many lines to implement it properly?
struct {
atomic_t cur;
int max;
} ss_t;
void spin_init(ss_t *ss, int max)
{
&ss->cur = ATOMIC_INIT(0);
&ss->max = max;
}
void spin_take(ss_t *ss)
{
preempt_disable();
while (unlikely(!atomic_add_unless(&ss->cur, 1, &ss->max))) {
while (atomic_read(&ss->cur) == ss->max)
cpu_relax();
}
}
void spin_put(ss_t *ss)
{
smp_mb();
atomic_dec(&ss->cur);
preempt_enable();
}
About the same number as down_spin(). And it is much harder to
misuse. So LOC isn't such a great argument for this kind of thing.
My 2c
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Matthew Wilcox <matthew@wil.cx>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: down_spin() implementation
Date: Fri, 28 Mar 2008 11:01:24 +1100 [thread overview]
Message-ID: <200803281101.25037.nickpiggin@yahoo.com.au> (raw)
Message-ID: <20080328000124.Kap4_IfOFvNCu4ngdh9Ay6XTYy60u7wkPasC17TomL4@z> (raw)
In-Reply-To: <20080327141508.GL16721@parisc-linux.org>
On Friday 28 March 2008 01:15, Matthew Wilcox wrote:
> On Wed, Mar 26, 2008 at 01:29:58PM -0700, Luck, Tony wrote:
> > This looks a lot cleaner than my ia64 specific code that
> > used cmpxchg() for the down() operation and fetchadd for
> > the up() ... using a brand new semaphore_spin data type.
>
> I did brifly consider creating a spinaphore data type, but it's
> significantly less code to create down_spin().
>
> > It appears to work ... I tried to do some timing comparisons
> > of this generic version against my arch specific one, but the
> > hackbench test case has a run to run variation of a factor of
> > three (from 1min9sec to 3min44sec) so it is hopeless to try
> > and see some small percentage difference.
>
> Thanks for testing and putting this together in patch form. I've fixed it
> up to address Jens' astute comment and added it to my semaphore patchset.
>
> http://git.kernel.org/?p=linux/kernel/git/willy/misc.git;a=shortlog;h=semap
>hore-20080327
>
> Stephen, I've updated the 'semaphore' tag to point ot the same place as
> semaphore-20080327, so please change your linux-next tree from pulling
> semaphore-20080314 to just pulling plain 'semaphore'. I'll use this
> method of tagging from now on.
>
> Here's the edited patch.
>
> commit 517df6fedc88af3f871cf827a62ef1a1a2073645
> Author: Matthew Wilcox <matthew@wil.cx>
> Date: Thu Mar 27 09:49:26 2008 -0400
>
> Add down_spin()
>
> ia64 would like to use a semaphore in flush_tlb_all() as it can have
> multiple tokens. Unfortunately, it's currently nested inside a
> spinlock, so they can't sleep. down_spin() is the cheapest solution to
> implement.
Uhm, how do you use this exactly? All other holders of this
semaphore must have preempt disabled and not sleep, right? (and
so you need a new down() that disables preempt too)
So the only difference between this and a spinlock I guess is
that waiters can sleep rather than spin on contention (except
this down_spin guy, which sleeps).
Oh, I see from the context of Tony's message... so this can *only*
be used when preempt is off, and *only* against other down_spin
lockers.
Bad idea to be hack this into the semaphore code, IMO. It would
take how many lines to implement it properly?
struct {
atomic_t cur;
int max;
} ss_t;
void spin_init(ss_t *ss, int max)
{
&ss->cur = ATOMIC_INIT(0);
&ss->max = max;
}
void spin_take(ss_t *ss)
{
preempt_disable();
while (unlikely(!atomic_add_unless(&ss->cur, 1, &ss->max))) {
while (atomic_read(&ss->cur) == ss->max)
cpu_relax();
}
}
void spin_put(ss_t *ss)
{
smp_mb();
atomic_dec(&ss->cur);
preempt_enable();
}
About the same number as down_spin(). And it is much harder to
misuse. So LOC isn't such a great argument for this kind of thing.
My 2c
next prev parent reply other threads:[~2008-03-28 0:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 20:49 What if a TLB flush needed to sleep? Luck, Tony
2008-03-25 20:49 ` Luck, Tony
[not found] ` <1FE6DD409037234FAB833C420AA843ECE9DF60-7XlYjKTK0pM64kNsxIetb7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-03-25 21:47 ` Alan Cox
2008-03-25 21:47 ` Alan Cox
2008-03-26 12:32 ` Matthew Wilcox
2008-03-26 12:32 ` Matthew Wilcox
[not found] ` <20080326123239.GG16721-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
2008-03-26 20:29 ` Luck, Tony
2008-03-26 20:29 ` Luck, Tony
[not found] ` <1FE6DD409037234FAB833C420AA843ECE9EB1C-7XlYjKTK0pM64kNsxIetb7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-03-27 8:09 ` Jens Axboe
2008-03-27 8:09 ` Jens Axboe
2008-03-27 14:15 ` down_spin() implementation Matthew Wilcox
2008-03-27 14:15 ` Matthew Wilcox
[not found] ` <20080327141508.GL16721-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
2008-03-28 0:01 ` Nick Piggin [this message]
2008-03-28 0:01 ` Nick Piggin
[not found] ` <200803281101.25037.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>
2008-03-28 12:45 ` Matthew Wilcox
2008-03-28 12:45 ` Matthew Wilcox
[not found] ` <20080328124517.GQ16721-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
2008-03-28 21:16 ` Luck, Tony
2008-03-28 21:16 ` Luck, Tony
[not found] ` <1FE6DD409037234FAB833C420AA843ECF237C0-7XlYjKTK0pM64kNsxIetb7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2008-03-28 23:48 ` Arnd Bergmann
2008-03-28 23:48 ` Arnd Bergmann
2008-03-29 1:04 ` Nick Piggin
2008-03-29 1:04 ` Nick Piggin
2008-03-28 4:51 ` Stephen Rothwell
2008-03-28 4:51 ` Stephen Rothwell
[not found] ` <20080328155107.e9d8866c.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
2008-03-28 5:03 ` Nick Piggin
2008-03-28 5:03 ` Nick Piggin
[not found] ` <200803281603.34134.nickpiggin-/E1597aS9LT0CCvOHzKKcA@public.gmane.org>
2008-03-28 12:46 ` Matthew Wilcox
2008-03-28 12:46 ` Matthew Wilcox
2008-03-28 12:51 ` Jens Axboe
2008-03-28 12:51 ` Jens Axboe
[not found] ` <20080328125104.GK12346-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>
2008-03-28 13:17 ` Matthew Wilcox
2008-03-28 13:17 ` Matthew Wilcox
[not found] ` <20080328131750.GT16721-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
2008-03-28 13:24 ` Jens Axboe
2008-03-28 13:24 ` Jens Axboe
2008-03-26 19:25 ` What if a TLB flush needed to sleep? Christoph Lameter
2008-03-26 19:25 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0803261222090.31000-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2008-03-26 20:29 ` Thomas Gleixner
2008-03-26 20:29 ` Thomas Gleixner
[not found] ` <alpine.LFD.1.00.0803262121440.3781-dbfLifZv8x0yMciVaGeJ0d53zsg1cpMQ@public.gmane.org>
2008-03-27 1:19 ` Christoph Lameter
2008-03-27 1:19 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0803261817110.1115-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2008-03-27 13:20 ` Peter Zijlstra
2008-03-27 13:20 ` Peter Zijlstra
2008-03-27 18:44 ` Christoph Lameter
2008-03-27 18:44 ` Christoph Lameter
[not found] ` <Pine.LNX.4.64.0803271143540.7531-RYO/mD75kfhx2SFC9UQUAuF7EQX82lMiAL8bYrjMMd8@public.gmane.org>
2008-03-28 9:59 ` Peter Zijlstra
2008-03-28 9:59 ` Peter Zijlstra
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=200803281101.25037.nickpiggin@yahoo.com.au \
--to=nickpiggin-/e1597as9lt0ccvohzkkca@public.gmane.org \
--cc=linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=matthew-Ztpu424NOJ8@public.gmane.org \
--cc=sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org \
--cc=tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox