[Nexus 6  Original Android Development] bbedward:
Since I was called :p

First of all I haven't numerically quantified BFS as performing better, but it isn't easy to numerically measure interactivity anyway. Any typical android benchmark is about the same although they are the easiest things to manipulate.

I will say, BFS is a significantly different design than CFS. (Doc: https://github.com/bbedward/ZenKernel_Shamu/raw/master/Documentation/scheduler/sched-BFS.txt). Shared runqueue, deadlines, insertion, tick accounting, not using idle time or other things to be fair or avoid starvation.

Anyway, the last time I've seen BFS on android is years ago. Today we have a much different android, and much different hardware. It isn't unreasonable to consider that modern hardware + modern android (that we interact with differently than ever before) - In conjunction with modern BFS is giving different results than it did before.

I know CM did a blind-test years ago with BFS and CFS kernels. Not telling the user which was which - and they deemed that there was no difference and opted to keep it stock. However much different hardware, much less multi-threading on single core devices and what not.

What I'm saying is, maybe there's nothing noticeable (I'll leave that up to the user to determine - and obviously I advocate it as a good change) - but there are plenty of reasons why there could be a difference noticed.

I think the possibility of a major regression being introduced by google, caf, etc. to CFS is pretty much nonexistent. Too many other factors to consider in terms of design, etc.

Much more likely if there is a real difference it's due to the significantly different design that suits interactivity and low latency well (BFS is designed specifically for the latency-sensitive, interactivity-oriented desktop workload to begin with) . A UI jitter is an instance of an "interactive" task being starved briefly - or wrongly considered a non-interactive task and preempted by something else. Something we don't see happening on the BFS design (Because tasks waking up have an earlier virtual deadline and always preempt tasks of equal priority). CFS is after all designed to scale to EVERY possible Linux workload. 5000 CPUs or 4 they use the same CPU scheduler.

In a situation where we care mostly about interactivity (like on a Desktop or on an Android device) - we pretty much always want interactive tasks to preempt non-interactive ones. This happens on both CFS and BFS, however CFS does this by using sleep+run time to determine if a task is interactive or not (if interactive it should preempt tasks of the same priority and so on). However, there are many edge case scenarios where this isn't accurate (an interactive task is sleeping waiting for user input, I/O request, etc. - could be flagged as non-interactive and preempted by something else)

On BFS, sleeping tasks that are waking up (and have not used all their CPU time) have the earliest deadlines - and they will always preempt tasks of the same nice/priority level. All by design, rather than any calculations - etc.

Also not different before why would it be now? BFS evolution, improved mainline synchronizations, significantly different hardware running with more CPUs, higher frequencies. A significantly different android UI interaction than we had a few years ago.

(Posted here because [MENTION=3863530]Steady Hawkin[/MENTION] asked me to respond, but I don't wanna clutter imoseyons thread)

(Some birdies have said that BFS on the n9 is also really smooth, that's arm64/tegra hardware)