Re: [PATCH V2 0/4] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task
On 23-11-16, 19:01, Steve Muckle wrote:
> I know this has already gone in, but can you expand on the unmet
> guarantees mentioned here just for my own (and perhaps others')
> understanding?
Sure. This is the simplified form of your original patch:
@@ -71,7 +73,7 @@ static bool sugov_should_update_freq(struct sugov_policy
*sg_policy, u64 time)
{
s64 delta_ns;
- if (sg_policy->work_in_progress)
+ if (sg_policy->thread_active)
return false;
if (unlikely(sg_policy->need_freq_update)) {
+static int sugov_thread(void *data)
{
...
+ do {
...
+ set_current_state(TASK_RUNNING);
+ /* Issue request. */
+ mutex_lock(&sg_policy->slow_lock);
+ __cpufreq_driver_target(sg_policy->policy,
+ sg_policy->next_freq,
+ CPUFREQ_RELATION_L);
+ mutex_unlock(&sg_policy->slow_lock);
+
+ sg_policy->thread_active = false;
...
+ schedule();
+
+ } while (!kthread_should_stop());
+ return 0;
}
static void sugov_irq_work(struct irq_work *irq_work)
@@ -349,7 +382,7 @@ static void sugov_irq_work(struct irq_work *irq_work)
struct sugov_policy *sg_policy;
sg_policy = container_of(irq_work, struct sugov_policy, irq_work);
- schedule_work_on(smp_processor_id(), &sg_policy->work);
+ wake_up_process(sg_policy->thread);
}
Consider that the thread has just got a chance to run and has set
'thread_active' to false from sugov_thread(), i.e. schedule() isn't called yet.
At this time if sugov_should_update_freq() gets called again, it will return
'true', and eventually we will land into sugov_irq_work() and that will call
wake_up_process(). But the process is already running and haven't slept yet.
I am not sure how it works but I don't expect the thread to go to sleep again at
this point of time.
And in this particular case we will end up not evaluating the load and doing
DVFS for period = 2 * rate_limit_us, whereas we wanted to do that every
rate_limit microseconds.
Of course a simple kthread would have been better instead of a kthread + work if
this wasn't the case.
Does that sound reasonable or Am I missing something ?
--
viresh
Re: [PATCH V2 0/4] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task
Hi Viresh, On Tue, Nov 15, 2016 at 01:53:19PM +0530, Viresh Kumar wrote: > This work was started by Steve Muckle, where he used a simple kthread > instead of kthread-worker and that wasn't sufficient as some guarantees > weren't met. I know this has already gone in, but can you expand on the unmet guarantees mentioned here just for my own (and perhaps others') understanding? thanks, Steve
[PATCH V2 0/4] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task
Hi, If slow path frequency changes are conducted in a SCHED_OTHER context then they may be delayed for some amount of time, including indefinitely, when real time or deadline activity is taking place. Move the slow path to a real time kernel thread using the kthread worker infrastructure. In the future the thread should be made SCHED_DEADLINE. The RT priority is arbitrarily set to 50 for now. This was tested with Hackbench on ARM Exynos, dual core A15 platform and no regressions were seen. The third patch has more details on it. This work was started by Steve Muckle, where he used a simple kthread instead of kthread-worker and that wasn't sufficient as some guarantees weren't met. I was wondering if the same should be done for ondemand/conservative governors as well ? V1->V2: - first patch is new based on Peter's suggestions. - fixed indented label - Moved kthread creation/destruction into separate routines - Used MACRO instead of magic number '50' - minor formatting, commenting and improved commit logs -- viresh Viresh Kumar (4): cpufreq: schedutil: Avoid indented labels cpufreq: schedutil: enable fast switch earlier cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task cpufreq: schedutil: irq-work and mutex are only used in slow path kernel/sched/cpufreq_schedutil.c | 119 --- 1 file changed, 99 insertions(+), 20 deletions(-) -- 2.7.1.410.g6faf27b
