linux-kernel - Re: [patch] sched: optimize activate_task for RT task

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, 15 Nov 2006 08:00:19 +0100
From:	Mike Galbraith <efault@....de>
To:	"Chen, Kenneth W" <kenneth.w.chen@...el.com>
Cc:	nickpiggin@...oo.com.au, 'Ingo Molnar' <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch] sched: optimize activate_task for RT task - v2

On Tue, 2006-11-14 at 15:55 -0800, Chen, Kenneth W wrote:
> Perhaps the following is a better patch compare to earlier one.
> The p->sleep_type are only for SCHED_NORMAL as well, so we can
> bypass them altogether in one shot.
> 
> 
> 
> 
> RT task does not participate in interactiveness priority and thus
> shouldn't be bothered with timestamp and p->sleep_type manipulation
> when task is being put on run queue.  Bypass all of the them with
> a single if (rt_task) test.

Personally, I think it's best to leave it as it is.  With that change,
if someone changes policy while the task is waiting to get cpu, it will
be requeued, and the on-runqueue bonus logic will then end up using
wildly inaccurate information.  Unlikely, true (hmm, what about PI...
afaik, works both ways), but from the correctness standpoint, I think
the information we use in heuristics should always be kept as accurate
as possible.

If you want to shave cycles, IMHO the better investment would be to get
rid of the division in schedule().

	-Mike

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