Hi Steven,

On 8 January 2013 03:59, Steven Rostedt [off-list ref] wrote:

On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:

quoted

quoted

By default, I would suggest for cache locality,
that we try to keep it on the same CPU. But if there's a better CPU to
run on, it runs there.

That would break our intention behind this routine. We should run
it on a cpu which we think is the best one for it power/performance wise.

If you are running on a big.Little box sure. But for normal (read x86 ;)
systems, it should probably stay on the current CPU.

But that's not the purpose of this new call. If the caller want it to be on
local cpu, he must not use this call. It is upto the core routine
(sched_select_cpu()
in our case) to decide where to launch it. If we need something special for x86,
we can hack this routine.

Even for non bigLITTLE systems, we may want to run a work on non-idle cpu and
so we can't guarantee local cpu here.

quoted

So, i would like to call the sched_select_cpu() routine from this routine to
get the suggested cpu.

Does the caller need to know? Or if you have a big.LITTLE setup, it
should just work automagically?

Caller wouldn't know, he just needs to trust on sched_select_cpu() to give the
most optimum cpu.

Again, it is not only for big LITTLE, but for any SMP system, where we
don't want
an idle cpu to do this work.

quoted

I don't think we need it :(
It would be a new API, with zero existing users. And so, whomsoever uses
it, should know what exactly he is doing :)

Heh, you don't know kernel developers well do you? ;-)

I agree with you, but we don't need to care for foolish new code here.

Once a new API is added to the kernel tree, it quickly becomes
(mis)used.

Its true with all pieces of code in kernel and we really don't need to take
care of such users here :)