From: Chris Metcalf <cmetcalf@ezchip.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Manfred Spraul <manfred@colorfullife.com>,
Oleg Nesterov <oleg@redhat.com>,
Kirill Tkhai <ktkhai@parallels.com>,
<linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles
Date: Tue, 28 Apr 2015 14:00:48 -0400 [thread overview]
Message-ID: <553FCAD0.9090403@ezchip.com> (raw)
In-Reply-To: <20150428174323.GL5029@twins.programming.kicks-ass.net>
On 04/28/2015 01:43 PM, Peter Zijlstra wrote:
> On Tue, Apr 28, 2015 at 12:58:55PM -0400, Chris Metcalf wrote:
>> On 04/28/2015 12:40 PM, Peter Zijlstra wrote:
>>> On Tue, Apr 28, 2015 at 11:53:21AM -0400, Chris Metcalf wrote:
>>>
>>>> The reason we use two 32-bit fields on tilepro is that the only available
>>>> atomic instruction is tns (test and set), which sets a 32-bit "1" value
>>>> into the target memory and returns the old 32-bit value.
>>> And you want a ticket lock as opposed to the test-and-set lock because
>>> with 64 tiles starvation under contention is a real worry?
>> We see substantial unfairness under load with a plain spinlock,
>> basically because nearer cores on the mesh network can exponentially
>> crowd out further cores. The ticket lock avoids that, though we
>> have to be careful to do backoff when checking the lock to avoid
>> DDoS in the mesh network.
> Does your arch have 16bit atomic load/stores ? If so, would something
> like the below not make sense?
Yes, tilepro can do 16-bit atomic load/stores. The reason we didn't use
your approach (basically having tns provide locking for the head/tail)
is just a perceived efficiency gain from rolling the tns lock into the head.
The current tilepro arch_spin_lock() is just three mesh network transactions
(tns, store, load). Your proposed spin lock is five (tns, load, store,
store, load).
Or, looking it from a core-centric perspective, the current arch_spin_lock()
only has to wait on requests from the mesh network twice (tns, load),
basically
once for each member of the lock structure; your proposed version is three
(tns, load, load).
I don't honestly know how critical this difference is, but that's why I
designed it the way I did.
I think your goal with your proposed redesign is being able to atomically
read head and tail together for arch_spin_unlock_wait(), but I don't see
why that's better than just reading head, checking it's not equal to tail
with a separate read, then spinning waiting for head to change.
>
> typedef struct {
> union {
> struct {
> unsigned short head;
> unsigned short tail;
> };
> unsigned int tickets;
> };
> unsigned int lock;
> } arch_spinlock_t;
>
> static inline void ___tns_lock(unsigned int *lock)
> {
> while (tns(lock))
> cpu_relax();
> }
>
> static inline void ___tns_unlock(unsigned int *lock)
> {
> WRITE_ONCE(*lock, 0);
> }
>
> static inline void arch_spin_lock(arch_spinlock_t *lock)
> {
> unsigned short head, tail;
>
> ___tns_lock(&lock->lock); /* XXX does the TNS imply a ___sync? */
> head = lock->head;
> lock->head++;
> ___tns_unlock(&lock->lock);
>
> while (READ_ONCE(lock->tail) != head)
> cpu_relax();
> }
>
> static inline void arch_spin_unlock(arch_spinlock_t *lock)
> {
> /*
> * can do with regular load/store because the lock owner
> * is the only one going to do stores to the tail
> */
> unsigned short tail = READ_ONCE(lock->tail);
> smp_mb(); /* MB is stronger than RELEASE */
> WRITE_ONCE(lock->tail, tail + 1);
> }
>
> static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> {
> union {
> struct {
> unsigned short head;
> unsigned short tail;
> };
> unsigned int tickets;
> } x;
>
> for (;;) {
> x.tickets = READ_ONCE(lock->tickets);
> if (x.head == x.tail)
> break;
> cpu_relax();
> }
> }
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
next prev parent reply other threads:[~2015-04-28 18:01 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150217104516.12144.85911.stgit@tkhai>
2015-02-17 10:47 ` Kirill Tkhai
2015-02-17 12:12 ` Peter Zijlstra
2015-02-17 12:36 ` Kirill Tkhai
2015-02-17 12:45 ` Peter Zijlstra
2015-02-17 13:05 ` Peter Zijlstra
2015-02-17 16:05 ` Paul E. McKenney
2015-02-17 18:01 ` Paul E. McKenney
2015-02-17 18:23 ` Peter Zijlstra
2015-02-17 21:45 ` Paul E. McKenney
2015-02-18 13:41 ` Peter Zijlstra
2015-02-17 18:36 ` Peter Zijlstra
2015-02-17 21:52 ` Paul E. McKenney
2015-02-18 13:47 ` Peter Zijlstra
2015-02-18 18:43 ` Paul E. McKenney
2015-02-18 15:53 ` Oleg Nesterov
2015-02-18 16:11 ` Peter Zijlstra
2015-02-18 16:32 ` Oleg Nesterov
2015-02-18 19:23 ` Paul E. McKenney
2015-02-18 15:59 ` Oleg Nesterov
2015-02-18 19:14 ` Manfred Spraul
2015-02-18 22:43 ` Peter Zijlstra
2015-02-19 14:19 ` Oleg Nesterov
2015-02-20 18:28 ` Manfred Spraul
2015-02-20 18:45 ` Peter Zijlstra
2015-02-20 20:23 ` Oleg Nesterov
2015-02-21 12:54 ` Peter Zijlstra
2015-04-25 19:56 ` Paul E. McKenney
2015-04-26 10:52 ` Paul E. McKenney
2015-04-28 14:33 ` Peter Zijlstra
2015-04-28 15:53 ` Chris Metcalf
2015-04-28 16:24 ` Peter Zijlstra
2015-04-28 16:44 ` [PATCH] spinlock: clarify doc for raw_spin_unlock_wait() Chris Metcalf
2015-04-29 17:34 ` Manfred Spraul
2015-04-28 17:33 ` [PATCH 1/2] tile: modify arch_spin_unlock_wait() semantics Chris Metcalf
2015-04-28 17:33 ` [PATCH 2/2] tile: use READ_ONCE() in arch_spin_is_locked() Chris Metcalf
2015-04-28 16:40 ` [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles Peter Zijlstra
2015-04-28 16:58 ` Chris Metcalf
2015-04-28 17:43 ` Peter Zijlstra
2015-04-28 18:00 ` Chris Metcalf [this message]
2015-04-28 18:24 ` Peter Zijlstra
2015-04-28 18:38 ` Chris Metcalf
2015-04-28 14:32 ` Peter Zijlstra
2015-04-28 20:33 ` Paul E. McKenney
2015-02-21 3:26 ` Paul E. McKenney
2015-02-23 18:29 ` Paul E. McKenney
2015-02-18 17:05 ` [tip:sched/core] sched: Clarify ordering between task_rq_lock() and move_queued_task() tip-bot for 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=553FCAD0.9090403@ezchip.com \
--to=cmetcalf@ezchip.com \
--cc=jpoimboe@redhat.com \
--cc=ktkhai@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.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
Powered by JetHome