linux-kernel - Re: [RFC PATCH] sched: find the latest idle cpu

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: <alpine.LFD.2.10.1401162114051.28907@knanqh.ubzr>
Date:	Thu, 16 Jan 2014 21:40:26 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Daniel Lezcano <daniel.lezcano@...aro.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	linaro-kernel@...ts.linaro.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, mingo@...hat.com,
	Michael wang <wangyun@...ux.vnet.ibm.com>,
	fengguang.wu@...el.com
Subject: Re: [RFC PATCH] sched: find the latest idle cpu

On Thu, 16 Jan 2014, Daniel Lezcano wrote:

> The question raised when I looked closely how to fully integrate cpuidle with
> the scheduler; in particular, the idle time.
> The scheduler idle time is not the same than the cpuidle idle time.
> A cpu can be idle for the scheduler 1s but it could be interrupted several
> times by an interrupt thus the idle time for cpuidle is different. But anyway
> ...

The idle task would run each time an interrupt has been serviced, either 
to yield to a newly awaken task or to put the CPU back to sleep.  In the 
later case the idle task may simply do extra idleness accounting 
locally.  If the former case happens most of the time then the scheduler 
idle time would be most representative already.

And if threaded IRQs are used then the the scheduler idle time would be 
the same as cpuidle's.

> > We need the idle task, since we need to DO something to go idle, the
> > scheduler needs to pick a task to go do that something. This is the idle
> > task.
> > 
> > You cannot get rid of that.
> > 
> > In fact, the 'doing' of that task is running much of the cpuidle code,
> > so by getting rid of it, there's nobody left to execute that code.
> > 
> > Also, since its already running that cpuidle stuff, integrating it more
> > closely with the scheduler will not in fact change much, it will still
> > run it.
> > 
> > Could of course be I'm not reading what you meant to write, if so, do
> > try again ;-)
> 
> Well, I wanted to have a clarification of what was your feeling about how to
> integrate cpuidle in the scheduler. If removing the idle task (in the future)
> does not make sense for you, I will not insist. Let's see how the code evolves
> by integrating cpuidle and we will figure out what will be the impact on the
> idle task.

I think we should be able to get rid of architecture specific idle 
loops.  The idle loop could be moved close to the scheduler and 
architectures would only need to provide a default CPU halt method for 
when there is nothing else registered with the cpuidle subsystem.


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