[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171220091712.kd2nx5rf3dgila45@hirez.programming.kicks-ass.net>
Date: Wed, 20 Dec 2017 10:17:12 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Rafael Wysocki <rjw@...ysocki.net>, Ingo Molnar <mingo@...hat.com>,
linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
dietmar.eggemann@....com, morten.rasmussen@....com,
juri.lelli@...hat.com, tkjos@...roid.com, joelaf@...gle.com,
linux-kernel@...r.kernel.org, patrick.bellasi@....com
Subject: Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization
update flags
On Wed, Dec 20, 2017 at 02:18:59PM +0530, Viresh Kumar wrote:
> On 20-12-17, 09:31, Peter Zijlstra wrote:
> What about this case: A CFS task is running currently and an RT task
> is enqueued.
>
> - Is it always the case that the CFS task is preempted immediately and
> the CPU is given to RT task ? I was talking to Vincent earlier and
> he told me that for certain configurations the CFS task may keep
> running until the next tick.
>
> - What if the CFS task has disabled preemption ?
>
> - More corner cases like this ?
If there is a runnable RT task we'll schedule to it ASAP. This means
for:
CONFIG_PREEMPT=y
either immediately or when next preempt_enable() hits a 0
preempt_count.
CONFIG_PREEMPT=n
on any next kernel preemption point or when returning to userspace.
But this is not something we should worry about.
Powered by blists - more mailing lists