linux-kernel - Re: [PATCH] sched/rt: Don't pull tasks of throttled rt_rq in pre_schedule

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] [day] [month] [year] [list]

Message-ID: <1359082066.21576.198.camel@gandalf.local.home>
Date:	Thu, 24 Jan 2013 21:47:46 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Kirill Tkhai <tkhai@...dex.ru>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: [PATCH] sched/rt: Don't pull tasks of throttled rt_rq in
 pre_schedule_rt()

Sorry for the late reply.

On Tue, 2012-12-25 at 12:20 +0400, Kirill Tkhai wrote:
> The patch aims not to pull tasks of throttled rt_rqs
> in pre_schedule_rt() because thay are not able to be
> picked in pick_next_task_rt().
> 
> There are three places where pull_rt_task() is used:
> 
> 1)pre_schedule_rt()
> If we pull a task of a throttled rt_rq it won't be picked
> by pick_next_task_rt(), because throttled tasks are dequeued
> by sched_rt_runtime_exceeded(). So this action is unnecessary.
> 
> 2)prio_changed_rt()
> A pulled task of higher priority leads to reschedule of current
> rq's task. The schedule() will occur with the first hw interrupt
> so there is possibility the throttled rt_rq will unthrottle and
> it will be queued during this time.
> (In case of preemptable kernel schedule() occurs during
> preempt_enable() in call of __task_rq_unlock(). But its lock is
> unlocked so there is no guarantee the rt_rq won't be queued).
> 
> 3)switched_from_rt()
> The same as prio_changed_rt().

These are pretty much hot paths. They are done rather commonly. My
concern is that we are adding overhead here that can be done in a much
less common path.

I'm wondering if we couldn't use the pushable_task list for finding the
next highest rt task. That may even speed up the fast path if we do so.

Then, when an rq gets throttled, which shouldn't be often, we can remove
all the tasks from the pushable_task list, and add them back when the rq
is comes back up.

Then, by just using the pushable_task list, we can achieve this goal.

We have to look to see what prevents us from using that list.

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