linux-kernel - Re: [PATCH v3 1/2] sched/rt: Check to push the task when changing its affinity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADcy93VtCQE_JSe-o-bAB7W9CuUaffcRyGoK9SZZzHYh3_6rsw@mail.gmail.com>
Date:	Fri, 13 Feb 2015 11:38:08 +0800
From:	Xunlei Pang <pang.xunlei@...aro.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: [PATCH v3 1/2] sched/rt: Check to push the task when changing its affinity

On 13 February 2015 at 07:31, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Sun,  8 Feb 2015 23:51:25 +0800
> Xunlei Pang <pang.xunlei@...aro.org> wrote:
>
>
>> +     if (new_weight > 1 &&
>> +         rt_task(rq->curr) &&
>> +         !test_tsk_need_resched(rq->curr)) {
>> +             /*
>> +              * We own p->pi_lock and rq->lock. rq->lock might
>> +              * get released when doing direct pushing, however
>> +              * p->pi_lock is always held, so it's safe to assign
>> +              * the new_mask and new_weight to p below.
>> +              */
>> +             if (!task_running(rq, p)) {
>> +                     cpumask_copy(&p->cpus_allowed, new_mask);
>> +                     p->nr_cpus_allowed = new_weight;
>> +                     direct_push = 1;
>> +             } else if (cpumask_test_cpu(task_cpu(p), new_mask)) {
>> +                     cpumask_copy(&p->cpus_allowed, new_mask);
>> +                     p->nr_cpus_allowed = new_weight;
>> +                     if (!cpupri_find(&rq->rd->cpupri, p, NULL))
>> +                             goto update;
>> +
>> +                     /*
>> +                      * At this point, current task gets migratable most
>> +                      * likely due to the change of its affinity, let's
>> +                      * figure out if we can migrate it.
>> +                      *
>> +                      * Is there any task with the same priority as that
>> +                      * of current task? If found one, we should resched.
>> +                      * NOTE: The target may be unpushable.
>> +                      */
>> +                     if (p->prio == rq->rt.highest_prio.next) {
>> +                             /* One target just in pushable_tasks list. */
>> +                             requeue_task_rt(rq, p, 0);
>
> What's the purpose of the requeue_task_rt() here?
>
>> +                             preempt_push = 1;
>> +                     } else if (rq->rt.rt_nr_total > 1) {
>> +                             struct task_struct *next;
>> +
>> +                             requeue_task_rt(rq, p, 0);
>
> And here? It may just be late and I'm tired, but it's not obvious to me.

If we're changing the affinity of the current running task, and there're also
other tasks with the same prio on the same cpu, we do the similar thing
as check_preempt_equal_prio(). But yes, this may have the same problem
you pointed out on the 2nd patch.

Thanks,
Xunlei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/