On 06/29, Peter Zijlstra wrote:
>
> On Mon, Jun 29, 2015 at 06:02:51AM +0200, Oleg Nesterov wrote:
>
> > If we change stop_two_cpus() to use stop_work_alloc_one() it can use
> > cpu_online(),
>
> So the one user of this actually needs cpu_active(); we do not want to
> go move tasks to an inactive
On 06/29, Peter Zijlstra wrote:
>
> On Fri, Jun 26, 2015 at 10:46:12PM +0200, Oleg Nesterov wrote:
>
> > So I am still not convinced... But probably I am too biased ;)
>
> I'm just a tad worried, I don't want to make the relatively cheap
> operation of stop_two_cpus() more expensive to the benefit
On Mon, Jun 29, 2015 at 06:02:51AM +0200, Oleg Nesterov wrote:
> > Btw. I can't understand the cpu_active() checks in stop_two_cpus().
> > Do we really need them?
>
> Ah, please ignore.
>
> Yes, we can't rely on stopper->enabled check in cpu_stop_queue_work(),
> cpu_stop_signal_done() does not
On Fri, Jun 26, 2015 at 10:46:12PM +0200, Oleg Nesterov wrote:
> > I would much prefer to keep stop_two_cpus() as proposed with taking two
> > cpu_stopper::lock instances and replacing the stop_cpu_mutex with a
> > percpu-rwsem.
>
> OK, lets avoid cpumask in stop_two_cpus,
>
> int
On Fri, Jun 26, 2015 at 10:46:12PM +0200, Oleg Nesterov wrote:
I would much prefer to keep stop_two_cpus() as proposed with taking two
cpu_stopper::lock instances and replacing the stop_cpu_mutex with a
percpu-rwsem.
OK, lets avoid cpumask in stop_two_cpus,
int
On Mon, Jun 29, 2015 at 06:02:51AM +0200, Oleg Nesterov wrote:
Btw. I can't understand the cpu_active() checks in stop_two_cpus().
Do we really need them?
Ah, please ignore.
Yes, we can't rely on stopper-enabled check in cpu_stop_queue_work(),
cpu_stop_signal_done() does not update
On 06/29, Peter Zijlstra wrote:
On Fri, Jun 26, 2015 at 10:46:12PM +0200, Oleg Nesterov wrote:
So I am still not convinced... But probably I am too biased ;)
I'm just a tad worried, I don't want to make the relatively cheap
operation of stop_two_cpus() more expensive to the benefit of
On 06/29, Peter Zijlstra wrote:
On Mon, Jun 29, 2015 at 06:02:51AM +0200, Oleg Nesterov wrote:
If we change stop_two_cpus() to use stop_work_alloc_one() it can use
cpu_online(),
So the one user of this actually needs cpu_active(); we do not want to
go move tasks to an inactive cpu.
So
On 06/26, Oleg Nesterov wrote:
>
> 2 cmpxchg()'s vs 2 spin_lock()'s. Plus wake_up(), but we can check
> waitqueue_active().
>
> Do you think thi will be noticeably slower?
>
> Of course, if it races with another stop_two_cpus/stop_cpus it will
> sleep, but in this case we need to wait anyway.
>
>
On 06/26, Oleg Nesterov wrote:
2 cmpxchg()'s vs 2 spin_lock()'s. Plus wake_up(), but we can check
waitqueue_active().
Do you think thi will be noticeably slower?
Of course, if it races with another stop_two_cpus/stop_cpus it will
sleep, but in this case we need to wait anyway.
And I
On 06/26, Peter Zijlstra wrote:
>
> On Fri, Jun 26, 2015 at 04:14:55AM +0200, Oleg Nesterov wrote:
> > Not sure.
> >
> > And note that this series kills stop_cpus_mutex, so that multiple
> > stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
> > do not overlap.
> >
> > Note also the
On Fri, Jun 26, 2015 at 04:14:55AM +0200, Oleg Nesterov wrote:
> Not sure.
>
> And note that this series kills stop_cpus_mutex, so that multiple
> stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
> do not overlap.
>
> Note also the changelog in 6/6, we can simplify + optimize
On 06/26, Peter Zijlstra wrote:
On Fri, Jun 26, 2015 at 04:14:55AM +0200, Oleg Nesterov wrote:
Not sure.
And note that this series kills stop_cpus_mutex, so that multiple
stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
do not overlap.
Note also the changelog in
On Fri, Jun 26, 2015 at 04:14:55AM +0200, Oleg Nesterov wrote:
Not sure.
And note that this series kills stop_cpus_mutex, so that multiple
stop_cpus()'s / stop_machine()'s can run in parallel if cpumask's
do not overlap.
Note also the changelog in 6/6, we can simplify + optimize this code
As always, forgot to mention...
Also. We can turn these stop_work_alloc/stop_work_free into the generic
helpers which (I think) can have more users.
On 06/26, Oleg Nesterov wrote:
>
> On 06/25, Peter Zijlstra wrote:
> >
> > On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
> > >
> >
On 06/25, Peter Zijlstra wrote:
>
> On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
> >
> > lock_stop_cpus_works(cpumask)
> > {
> > for_each_cpu(cpu, cpumask)
> > mutex_lock(per_cpu(cpu_stopper_task, cpu).work_mutex);
> > }
> >
> >
As always, forgot to mention...
Also. We can turn these stop_work_alloc/stop_work_free into the generic
helpers which (I think) can have more users.
On 06/26, Oleg Nesterov wrote:
On 06/25, Peter Zijlstra wrote:
On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
On 06/25, Peter Zijlstra wrote:
On Tue, Jun 23, 2015 at 07:24:16PM +0200, Oleg Nesterov wrote:
lock_stop_cpus_works(cpumask)
{
for_each_cpu(cpu, cpumask)
mutex_lock(per_cpu(cpu_stopper_task, cpu).work_mutex);
}
18 matches
Mail list logo
