linux-kernel - Re: [PATCH] sched: change pull_rt_task() to decrease time waiting on runqueue

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]

Date:	Wed, 18 May 2011 11:20:37 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Hillf Danton <dhillf@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Mike Galbraith <efault@....de>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Yong Zhang <yong.zhang0@...il.com>
Subject: Re: [PATCH] sched: change pull_rt_task() to decrease time waiting
 on runqueue

On Wed, 2011-05-18 at 22:54 +0800, Hillf Danton wrote:

> In short, if there are pushable tasks and if there are RQs,
> NOT LIMITED TO our RQ, in lower priority, tasks should be pushed to
> RQs as many as we could.

I understand what you are trying to do. But this change modifies a lot
of assumptions. Please supply test cases that shows how this helps.

Have a look at:

http://lwn.net/Articles/425583/

Where I did a bit of work just to make sure my change to sched_rt.c was
appropriate. Just coming up with scenarios may not be good enough.
Seeing it in practice is worth much more.

For example, you may be making the fast path slower. This may do what
you expect, with a hit in performance. I'm not sure I like that idea.

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