On 8 January 2013 03:59, Steven Rostedt firstname.lastname@example.org wrote:
On Mon, 2013-01-07 at 23:29 +0530, Viresh Kumar wrote:
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.
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.
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 :)