On Tue, Apr 28, 2015 at 04:32:35PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 25, 2015 at 12:56:03PM -0700, Paul E. McKenney wrote:
> > smp: Make control dependencies work on Alpha, improve documentation
> >
> > The current formulation of control dependencies fails on DEC Alpha,
> > w
On 04/28/2015 02:24 PM, Peter Zijlstra wrote:
A few questions:
On Tue, Apr 28, 2015 at 02:00:48PM -0400, Chris Metcalf wrote:
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? */
On Tue, Apr 28, 2015 at 02:00:48PM -0400, Chris Metcalf wrote:
> 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
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
a
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
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 o
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 loc
On Tue, Apr 28, 2015 at 11:53:21AM -0400, Chris Metcalf wrote:
> As you surmise, tilepro doesn't have 64-bit loads. So we are stuck with
> 32-bit loads on these two fields. It's true that spin_unlock_wait() can
> therefore falsely claim that the lock is unlocked, but it should be only a
> hint an
On 04/28/2015 10:33 AM, Peter Zijlstra wrote:
On Sun, Apr 26, 2015 at 03:52:13AM -0700, Paul E. McKenney wrote:
And then an smp_read_barrier_depends() would be needed either here
or embedded in apin_unlock_wait(). But we also need to check the
spin_unlock_wait() implementations to see if any a
On Sun, Apr 26, 2015 at 03:52:13AM -0700, Paul E. McKenney wrote:
> And then an smp_read_barrier_depends() would be needed either here
> or embedded in apin_unlock_wait(). But we also need to check the
> spin_unlock_wait() implementations to see if any are potentially
> vulnerable to compiler mis
On Sat, Apr 25, 2015 at 12:56:03PM -0700, Paul E. McKenney wrote:
> smp: Make control dependencies work on Alpha, improve documentation
>
> The current formulation of control dependencies fails on DEC Alpha, which
> does not respect dependencies of any kind unless an explicit memor
On Fri, Feb 20, 2015 at 07:45:51PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 20, 2015 at 07:28:16PM +0100, Manfred Spraul wrote:
>
> > >We need the full barrier to serialize STORE's as well, but probably we can
> > >rely on control dependancy and thus we only need rmb().
> > Do we need a full bar
On Sat, Apr 25, 2015 at 12:56:02PM -0700, Paul E. McKenney wrote:
> On Fri, Feb 20, 2015 at 07:45:51PM +0100, Peter Zijlstra wrote:
> > On Fri, Feb 20, 2015 at 07:28:16PM +0100, Manfred Spraul wrote:
> >
> > > >We need the full barrier to serialize STORE's as well, but probably we
> > > >can
> >
On Fri, Feb 20, 2015 at 07:26:21PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 20, 2015 at 07:28:16PM +0100, Manfred Spraul wrote:
> > Hi Oleg,
> >
> > my example was bad, let's continue with your example.
> >
> > And: If sem_lock() needs another smp_xmb(), then we must add it:
> > Some apps do
On Fri, Feb 20, 2015 at 09:23:19PM +0100, Oleg Nesterov wrote:
> On 02/20, Peter Zijlstra wrote:
> >
> > I think I agree with Oleg in that we only need the smp_rmb(); of course
> > that wants a somewhat elaborate comment to go along with it. How about
> > something like so:
> >
> > spin_unlock_
On Fri, Feb 20, 2015 at 07:28:16PM +0100, Manfred Spraul wrote:
> Hi Oleg,
>
> my example was bad, let's continue with your example.
>
> And: If sem_lock() needs another smp_xmb(), then we must add it:
> Some apps do not have a user space hot path, i.e. it seems that on
> some setups, we have mil
On 02/20, Peter Zijlstra wrote:
>
> I think I agree with Oleg in that we only need the smp_rmb(); of course
> that wants a somewhat elaborate comment to go along with it. How about
> something like so:
>
> spin_unlock_wait(&local);
> /*
>* The above spin_unlock_wait() forms a co
On Fri, Feb 20, 2015 at 07:28:16PM +0100, Manfred Spraul wrote:
> >We need the full barrier to serialize STORE's as well, but probably we can
> >rely on control dependancy and thus we only need rmb().
> Do we need a full barrier or not?
>
> I don't manage to create a proper line of reasoning.
I
Hi Oleg,
my example was bad, let's continue with your example.
And: If sem_lock() needs another smp_xmb(), then we must add it:
Some apps do not have a user space hot path, i.e. it seems that on some
setups, we have millions of calls per second.
If there is a race, then it will happen.
I've t
On 02/18, Peter Zijlstra wrote:
>
> On Wed, Feb 18, 2015 at 08:14:01PM +0100, Manfred Spraul wrote:
>
> > >spinlock_t local, global;
> > >bool force_global;
Yes, force_global (sma->complex_count) adds more complications, but
I think we can ignoire it in this discussion.
> > >bool my_lock(bool try
On Wed, Feb 18, 2015 at 08:14:01PM +0100, Manfred Spraul wrote:
> >spinlock_t local, global;
> >bool force_global;
> >bool my_lock(bool try_local)
> >{
> > if (try_local) {
> > spin_lock(&local);
> > if (!spin_is_locked(&global)) {
> > if (!force_glo
On Wed, Feb 18, 2015 at 05:32:56PM +0100, Oleg Nesterov wrote:
> On 02/18, Peter Zijlstra wrote:
> >
> > On Wed, Feb 18, 2015 at 04:53:34PM +0100, Oleg Nesterov wrote:
> > > On 02/17, Paul E. McKenney wrote:
> > > >
> > > > | mb | wmb | rmb | rbd | acq | rel | ctl |
> > > > --
Hi Oleg,
On 02/18/2015 04:59 PM, Oleg Nesterov wrote:
Let's look at sem_lock(). I never looked at this code before, I can be
easily wrong. Manfred will correct me. But at first glance we can write
the oversimplified pseudo-code:
spinlock_t local, global;
bool my_lock(bool try_l
On Wed, Feb 18, 2015 at 02:47:06PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 01:52:31PM -0800, Paul E. McKenney wrote:
> > I could do a table per communication style. For example, message
> > passing looks like this (give or take likely errors in the table):
> >
> > Side CPU
On 02/18, Peter Zijlstra wrote:
>
> On Wed, Feb 18, 2015 at 04:53:34PM +0100, Oleg Nesterov wrote:
> > On 02/17, Paul E. McKenney wrote:
> > >
> > > | mb | wmb | rmb | rbd | acq | rel | ctl |
> > > -+---+---+---+---+---+---+---+
> > >mb |
On Wed, Feb 18, 2015 at 04:53:34PM +0100, Oleg Nesterov wrote:
> On 02/17, Paul E. McKenney wrote:
> >
> > | mb | wmb | rmb | rbd | acq | rel | ctl |
> > -+---+---+---+---+---+---+---+
> >mb | Y | | Y | y | Y | |
(Forgot to add Manfred, resending)
Thanks Paul and Peter, this was the interesting reading ;)
This is almost off-topic (but see below), but perhaps memory-barriers.txt
could also mention spin_unlock_wait() to explain that _most probably_ it is
pointless without the memory barrier(s), and the barr
Thanks Paul and Peter, this was the interesting reading ;)
This is almost off-topic (but see below), but perhaps memory-barriers.txt
could also mention spin_unlock_wait() to explain that _most probably_ it is
pointless without the memory barrier(s), and the barrer before-or-after
unlock_wait() pai
On Tue, Feb 17, 2015 at 01:52:31PM -0800, Paul E. McKenney wrote:
> I could do a table per communication style. For example, message
> passing looks like this (give or take likely errors in the table):
>
> Side CPUTop CPU
> ---
> X = 1; r1 =
On Tue, Feb 17, 2015 at 01:45:22PM -0800, Paul E. McKenney wrote:
>
> documentation: Clarify control-dependency pairing
>
> This commit explicitly states that control dependencies pair normally
> with other barriers, and gives an example of such pairing.
>
> Reported-by: Peter Zijlstra
> Signed
On Tue, Feb 17, 2015 at 07:36:36PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 08:05:32AM -0800, Paul E. McKenney wrote:
> > > FWIW, we should probably update that table to include control
> > > dependencies too; we didn't (formally) have those back then I think.
> > >
> > > The blob un
On Tue, Feb 17, 2015 at 07:23:35PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 10:01:54AM -0800, Paul E. McKenney wrote:
> > > > The blob under SMP BARRIER PAIRING does not mention pairing with control
> > > > dependencies; and I'm rather sure I've done so.
> >
> > And here is a patch f
On Tue, Feb 17, 2015 at 08:05:32AM -0800, Paul E. McKenney wrote:
> > FWIW, we should probably update that table to include control
> > dependencies too; we didn't (formally) have those back then I think.
> >
> > The blob under SMP BARRIER PAIRING does not mention pairing with control
> > dependen
On Tue, Feb 17, 2015 at 10:01:54AM -0800, Paul E. McKenney wrote:
> > > The blob under SMP BARRIER PAIRING does not mention pairing with control
> > > dependencies; and I'm rather sure I've done so.
>
> And here is a patch for the control-dependency pairing. Thoughts?
The proposed patch does not
On Tue, Feb 17, 2015 at 08:05:32AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 17, 2015 at 02:05:23PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 17, 2015 at 01:12:58PM +0100, Peter Zijlstra wrote:
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -341,6 +341,22 @@ static s
On Tue, Feb 17, 2015 at 02:05:23PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2015 at 01:12:58PM +0100, Peter Zijlstra wrote:
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -341,6 +341,22 @@ static struct rq *task_rq_lock(struct ta
> > raw_spin_lock_irqsave(&p->p
On Tue, Feb 17, 2015 at 01:12:58PM +0100, Peter Zijlstra wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -341,6 +341,22 @@ static struct rq *task_rq_lock(struct ta
> raw_spin_lock_irqsave(&p->pi_lock, *flags);
> rq = task_rq(p);
> raw_sp
On Tue, Feb 17, 2015 at 03:36:50PM +0300, Kirill Tkhai wrote:
> > If we observe the new cpu value, we've acquired the new rq->lock and its
> > ACQUIRE will pair with the WMB to ensure we see the migrate value.
>
> Yes, I warried about new_cpu case.
>
> So, spin_lock() implies smp_rmb(). I used t
В Вт, 17/02/2015 в 13:12 +0100, Peter Zijlstra пишет:
> On Tue, Feb 17, 2015 at 01:47:01PM +0300, Kirill Tkhai wrote:
> >
> > We migrate a task using TASK_ON_RQ_MIGRATING state of on_rq:
> >
> > raw_spin_lock(&old_rq->lock);
> > deactivate_task(old_rq, p, 0);
> > p->on_rq = TASK_ON_RQ
On Tue, Feb 17, 2015 at 01:47:01PM +0300, Kirill Tkhai wrote:
>
> We migrate a task using TASK_ON_RQ_MIGRATING state of on_rq:
>
> raw_spin_lock(&old_rq->lock);
> deactivate_task(old_rq, p, 0);
> p->on_rq = TASK_ON_RQ_MIGRATING;
> set_task_cpu(p, new_cpu);
> raw_spin
We migrate a task using TASK_ON_RQ_MIGRATING state of on_rq:
raw_spin_lock(&old_rq->lock);
deactivate_task(old_rq, p, 0);
p->on_rq = TASK_ON_RQ_MIGRATING;
set_task_cpu(p, new_cpu);
raw_spin_unlock(&rq->lock);
I.e.:
write TASK_ON_RQ_MIGRATING
41 matches
Mail list logo
