On Fri, Oct 11, 2013 at 08:25:07PM +0200, Oleg Nesterov wrote: > On 10/11, Peter Zijlstra wrote: > > > > As a penance I'll start by removing all get_online_cpus() usage from the > > scheduler. > > I only looked at the change in setaffinity, > > > @@ -3706,7 +3707,6 @@ long sched_setaffinity(pid_t pid, const struct > > cpumask *in_mask) > > struct task_struct *p; > > int retval; > > > > - get_online_cpus(); > > rcu_read_lock(); > > Hmm. In theory task_rq_lock() doesn't imply rcu-lock, so > set_cpus_allowed_ptr() can miss the change in cpu_active_mask. But this > is probably fine, CPU_DYING does __migrate_task().
I'm fine with always doing sync_sched(); sync_rcu(); if that makes you feel better. But I thought that assuming that !PREEMPT sync_rcu() would imply sync_sched() was ok. I think the comment there even says as much. And task_rq_lock() will very much disable preemption; and thus we get what we want, right? In any case; the goal was to make either RCU or preempt-disable sufficient. > However. This means that sched_setaffinity() can fail if it races with > the failing cpu_down() (say, __cpu_notify(CPU_DOWN_PREPARE) fails). > Probably we do not really care, just this looks a bit confusing. Couldn't be bothered; failing hotplug will have side-effects any which way. > > @@ -3814,7 +3813,6 @@ long sched_getaffinity(pid_t pid, struct cpumask > > *mask) > > unsigned long flags; > > int retval; > > > > - get_online_cpus(); > > This change is probably fine in any case? Yes. > > rcu_read_lock(); > > > > retval = -ESRCH; > > @@ -3827,12 +3825,11 @@ long sched_getaffinity(pid_t pid, struct cpumask > > *mask) > > goto out_unlock; > > > > raw_spin_lock_irqsave(&p->pi_lock, flags); > > - cpumask_and(mask, &p->cpus_allowed, cpu_online_mask); > > + cpumask_and(mask, &p->cpus_allowed, cpu_active_mask); > > But I am just curious, is this change is strictly needed? No; we could do without. It really doesn't matter much if anything. I only did it because sched_setaffinity()->set_cpus_allowed_ptr() checks against active, not online. And had a sudden urge to make get/set symmetric -- totally pointless otherwise. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
