[Nexus S General] :
Hmm, kind of, they are both multitasking schedulers, but BFS favours latency and fairness over throughput whereas CFS tries to do both.

CFS was designed as a general purpose scheduler for embedded devices, desktops and servers. It was designed to scale to a massive number of cores and huge NUMA systems. It was designed as a 'one size fits all' implementation because they didn't want more than one CPU scheduler in the Linux kernel.

Like any 'one size fits all' product, it doesn't work particularly well over the full spectrum of devices. It scales very well and it's throughput is good but it's scheduling latency is not so good, and can go through the roof when the system is heavily loaded, although it has improved over the years.

SCHED_AUTOGROUP (the magic 200 line patch) improved the perceived interactivity of CFS on the desktop by automatically isolating processes in groups by session ID, which separates CPU burners from interactive tasks. However, this, in my opinion, is an ugly 'fix' because it simply masks the fact that CFS is completely broken when it comes to interactivity/latency on a loaded system. SCHED_AUTOGROUP also does absolutely nothing on Android, although you do see a number of kernel 'developers' enabling it (lol!).

Latency is of utmost importance when you are using a smartphone or desktop where you interact with a GUI or are using 'real time' apps such as media players. High scheduling latencies cause video jitter and dropped frames, mouse lag, UI lockups, audio buffer underruns, jerkiness and more, all which contribute to a poor user experience.

BFS was designed with low latency and the desktop in mind to resolve the issues mentioned above, which it does very well. In theory, it doesn't scale particularly well due to using a single runqueue for tasks, although I benchmarked it a while ago on a 24 core box for Con and the performance was still slightly better than CFS.

BFS is also substantially more 'fair' than CFS in the way it distributes CPU time to processes.

As for multitasking, on a desktop or embedded system, BFS gives substantially better interactivity whilst multitasking. Both CFS and BFS are designed to multitask, but BFS is designed to keep the latency low by design even when you have CPU burning jobs running such as a compile or other background tasks.

Furthermore, BFS is simpler and lower overhead and doesn't need a ton of tunables adjusting to get the best performance from it.

It is definitely more suited to phones and embedded devices than CFS. However, because of the choices the Android developers made, it's difficult to implement BFS as default in Android without causing performance regressions in some extreme corner cases.

It could be done if the framework was changed to nice background tasks at low priority instead of partitioning background tasks with cgroups, but as nice isn't particularly effective on CFS, I can understand why they made the choices they did.

---------- Post added at 02:39 PM ---------- Previous post was at 02:27 PM ----------

That's completely wrong and it shows a complete lack of understanding of the difference between CFS and BFS, and of multitasking in general. But it made me chuckle.

BFS is rigidly fair and distributes CPU time to tasks equally (assuming they are the same priority).