linux-kernel - Re: [PATCH] sched: fix conflict of schedule domain balance in RT scheduling

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: <1307112724.3667.58.camel@gandalf.stny.rr.com>
Date:	Fri, 03 Jun 2011 10:52:04 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Hillf Danton <dhillf@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>,
	Yong Zhang <yong.zhang0@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: fix conflict of schedule domain balance in RT
 scheduling

On Fri, 2011-06-03 at 22:30 +0800, Hillf Danton wrote:

> I note the comment related to cache-hot, it is fine for woken task even though
> cache-hot is considered to be nop for RT task,

I would not say cache-hot is a nop for RT tasks. Although RT tasks
should not depend on cache being hot, we don't want to go out of our way
to hurt RT tasks.

>  but what dose it help pushing
> RT tasks waiting on RQ?

What the lowest_mask returns is a mask of all cpus with the lowest
priority. Due to the double_lock_balance() we could have unlocked the rq
lock, and things could have changed. Thus, the current CPU could have
lowered its priority. Unlikely to be the case, but can happen.

If the lowest_mask has the task's CPU set, why push this RT task
somewhere else? Most likely the current CPU will not be set, but lets
not punish the RT task if it is.

-- Steve

--
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/