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>] [day] [month] [year] [list]
Date:	Tue, 17 Dec 2013 10:53:11 +0100
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Alex Shi <alex.shi@...aro.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Mike Galbraith <bitbucket@...ine.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:	Amit Kucheria <amit.kucheria@...aro.org>,
	Tuukka Tikkanen <tuukka.tikkanen@...aro.org>
Subject: power aware scheduler: remove the idle task ?


Hi all,

yes, another thread about the power aware scheduler :)

There have been a lot of discussions about the integrating the power 
management into the scheduler but it seems we are still turning around 
without agreeing on a consensus.

I would like to have some clarifications on one point.

Peter said in an email [1] :

"[...]

I think the scheduler simply wants to say: we expect to go idle for X 
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.

[...]"

I share 100% this opinion but that may imply the following:

1. the scheduler should get some information from the cpuidle framework 
in order to get the idle state it is supposed to go with its wakeup 
latency. Some of the heuristics of the cpuidle governors should be 
shared with the scheduler also in order to get how long it should stay idle.

2. the idle task should get some informations from the scheduler in 
order to get the idle time but it could be woken up several times, 
without preemption, thus it will need to recompute the expected idle 
time on its own and depending on the idle state, it will need to update 
the wakeup latency for the scheduler.

3. the pm qos is part of the constraint but also the idle balance 
constraints should be added for more integration.

4. ... certainly a lot of more things related to sched fair class with 
the scheduler.

So at the end, the resulting sub systems design is:

  -----------       -----------       ---------
| scheduler |<--->| idle task |<--->| cpuidle |
  -----------       -----------       ---------
      ^                                   ^
      |                                   |
       -----------------------------------

IMHO, this creates cyclical dependencies between scheduler, cpuidle
and idle task instead of integrating idle policy into the scheduler.

So, I am wondering if the idle task removal is something the maintainers 
had in mind when they talked about the power aware scheduler ?

The scheduler would gather all the idle informations and can modulate 
them regarding the behavior of the tasks (no details for now) and just 
tells the cpuidle framework to go the state fulfilling the constraints 
passed as parameter.

If the power aware scheduler implies the removal of the idle task, we 
could start by creating two paths in the scheduler, one with the old 
scheduler code with the idle task and the other one experimental without 
the idle task. Wouldn't make sense to investigate this first before 
moving code around to make the scheduler power aware ?

It would be nice if the maintainers and the other people deeply involved 
in the scheduler changes can share their opinion about that.

Thanks !

   -- Daniel

[1] https://lkml.org/lkml/2013/11/11/353

-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ