(Nearly) full tickless operation in 3.10

So, what's the solution for running >1 process per CPU with NO_HZ_FULL? Use syscalls as the hook for an implicit schedule 'pump'?

Requiring the user to explicitly schedule with 'sched_yield' to produce a cooperative multitasking scenario might work well. I've worked on enough realtime systems to know that this can yield good performance if done correctly (since your performance-critical sections never get interrupted without you saying so), though it occasionally bites you if you forget to yield somewhere, e.g. waiting for a lock. I know I would have liked to have had something like this in past system designs Instead, 'yielding' was done with coroutines or tasklets/threads.

What about having the boot cpu do all the scheduling for all the other CPUs? Basically treat the other CPUs like a thread pool and distribute processes. Is the cost of IPIs too much for this to be practical?

On a related note, it seems like quite a few multi-core SoC vendors have implemented their own patches for this behavior as well, e.g. Tilera's 'zero overhead' Linux. Glad to see if it becomes mainstream, maybe they'll all adopt just one way to do it.

http://www.6windblog.com/linux-based-fast-path/

After a little RTFC, I found that a HR-timer was used to calculate the next preemption point. I.e. instead of preempting on 100 Hz clock, it preempts exactly when the timeslot of the current process ends.

I got the same impression as you. I think the wording in the article is unfortunate.

> Even then, a running CPU will only disable the timer tick if there is a single runnable process on that CPU. As soon as a second process appears, the tick is needed so that the scheduler can make the necessary time-slice decisions

It's misleading to call it "the tick" if it's not fixed to the HZ any more, seems more like a preemption timer.

I believe that real tickless operation with pre-emptition is possible. Instead of recalculating that the same process keeps the CPU every n microseconds, until it does not, one could compute when another process would win the CPU and only schedule an interrupt and that time. Any periods in which the process would keep the CPU does not need interruption.

I know actually implementing this would not be trivial and I am not volunteering to do this myself.