On 14/08/14 03:57, Alex Shi wrote:
On 08/12/2014 09:50 PM, Chris Redpath wrote:
System services are generally started by init, whilst kernel threads are started by kthreadd. We do not want to give those tasks a head start, as this costs power for very little benefit. We do however wish to do that for tasks which the user launches.
Further, some tasks allocate per-cpu timers directly after launch which can lead to those tasks being always scheduled on a big CPU when there is no computational need to do so. Not promoting services to big CPUs on launch will prevent that unless a service allocates their per-cpu resources after a period of intense computation, which is not a common pattern.
It looks ok for me.
But in my mind, the service task can be moved to little cpu in late running, isn't it?
Yes, the issue is that some services set up their timers early in their lifetime, as called out in the description. When the task is running on a big CPU at the time, the timer is allocated there and tends to stay there unless we hotplug that CPU later and force those timers to be moved.
All we do here is to not give those tasks the same fork-boost that we give user-initiated tasks. They will still move big/little according to computational load as all other tasks do.
Signed-off-by: Chris Redpath chris.redpath@arm.com