On Fri, 2014-03-14 at 17:40 +0000, Chris Redpath wrote:
On 14/03/14 17:16, Jon Medhurst (Tixy) wrote:
[...]
Come to think of it, is it possible for big CPUs to be busy with other things and the little cores to go through the migrate process twice before the big CPU has acted on the first request? Does wake_for_idle_pull need to be a counter?
CPUs won't idle pull if they are busy, the request will be ignored
Does 'busy' include running a long running interrupt service routine just after it enables IRQs on coming out of idle? A CPU can be 'busy' even it there are not an tasks scheduled on it. I'm only raising things like this as something that code needs to be robust against, i.e. no oopses or deadlocks, not as something that necessarily effects normal use-case efficiency.
[...]
If the latter, perhaps the code is OK as it is in these patches, i.e. only finding one task at a time to migrate and waking one big CPU.
I'm still enjoying thinking about it :) One at a time is much simpler and we do need the bugfix to avoid a pinned task obscuring an unpinned one. I'm tempted to send you a respin with still one-at-a-time idle pulls but I haven't had testing time yet so it will have to be next week.
Sure, I won't push anything towards the direction of LSK for now.