/
linux-4.15-ck0.patch
11518 lines (11331 loc) · 337 KB
/
linux-4.15-ck0.patch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
This is a manual merge (and some compat additions) I did in order to get the -ck patchset running on the Linux 4.15 kernel.
These patches aimed at interactivity and used by the coolest of folks are originally by Con Kolivas. His development blog on the topic can be found at:
https://ck-hack.blogspot.com/
And the page hosting this port of the patchset can be found at:
https://github.com/kata198/con-ck-patches
I am currently running with this patchset in addition to the default archlinux patches applied to 4.15 on Archlinux ( www.archlinux.org ) on a 64-bit SMP/SMT system under Virtualbox. Things are stable, the only traceback in my kernel log are various things like "Detected Tx Hang" on my network card, which likely is an arifact of running under Virtualbox and not this patchset.
All this said, I did not do extensive research nor speed a month porting this, this is simply a one-night job spent porting my favourite kernel patchset over to the latest kernel. I make no promises that you will have similar stability, but on a similar system I don't see why you wouldn't have similar results.
Enjoy!!
I have noticed no hangs on anything, but this may indicate that there are changes between 4.14 and 4.15 which required additional code beyond what I provided and the port. I would still say it's completely safe and plan on continue running it myself, but if anyone has some free time may be worth looking into seeking out a "resolution." Again, I am also using virtualbox so this may just be some issue upon resume from suspend, and seems benign.
- Tim ( https://github.com/kata198/con-ck-patches )
--- a/arch/arc/configs/tb10x_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/arc/configs/tb10x_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -28,7 +28,7 @@
CONFIG_ARC_CACHE_LINE_SHIFT=5
CONFIG_HZ=250
CONFIG_ARC_BUILTIN_DTB_NAME="abilis_tb100_dvk"
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_COMPACTION is not set
CONFIG_NET=y
CONFIG_PACKET=y
--- a/arch/arm/configs/bcm2835_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/arm/configs/bcm2835_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -29,7 +29,7 @@
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM2835=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_KSM=y
CONFIG_CLEANCACHE=y
--- a/arch/arm/configs/imx_v6_v7_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/arm/configs/imx_v6_v7_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -47,7 +47,7 @@
CONFIG_PCI_IMX6=y
CONFIG_SMP=y
CONFIG_ARM_PSCI=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_HIGHMEM=y
CONFIG_CMA=y
--- a/arch/arm/configs/mps2_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/arm/configs/mps2_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -18,7 +18,7 @@
CONFIG_SET_MEM_PARAM=y
CONFIG_DRAM_BASE=0x21000000
CONFIG_DRAM_SIZE=0x1000000
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
--- a/arch/arm/configs/mxs_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/arm/configs/mxs_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -27,7 +27,7 @@
# CONFIG_ARCH_MULTI_V7 is not set
CONFIG_ARCH_MXS=y
# CONFIG_ARM_THUMB is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_NET=y
CONFIG_PACKET=y
--- a/arch/blackfin/configs/BF518F-EZBRD_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF518F-EZBRD_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF518=y
CONFIG_IRQ_TIMER0=12
# CONFIG_CYCLES_CLOCKSOURCE is not set
--- a/arch/blackfin/configs/BF526-EZBRD_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF526-EZBRD_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF526=y
CONFIG_IRQ_TIMER0=12
CONFIG_BFIN526_EZBRD=y
--- a/arch/blackfin/configs/BF527-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF527-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF527=y
CONFIG_BF_REV_0_1=y
CONFIG_IRQ_USB_INT0=11
--- a/arch/blackfin/configs/BF527-EZKIT-V2_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF527-EZKIT-V2_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF527=y
CONFIG_BF_REV_0_2=y
CONFIG_BFIN527_EZKIT_V2=y
--- a/arch/blackfin/configs/BF527-TLL6527M_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF527-TLL6527M_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -21,7 +21,7 @@
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF527=y
CONFIG_BF_REV_0_2=y
CONFIG_BFIN527_TLL6527M=y
--- a/arch/blackfin/configs/BF533-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF533-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BFIN533_EZKIT=y
CONFIG_TIMER0=11
CONFIG_CLKIN_HZ=27000000
--- a/arch/blackfin/configs/BF533-STAMP_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF533-STAMP_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_TIMER0=11
CONFIG_HIGH_RES_TIMERS=y
CONFIG_NOMMU_INITIAL_TRIM_EXCESS=0
--- a/arch/blackfin/configs/BF537-STAMP_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF537-STAMP_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF537=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_NOMMU_INITIAL_TRIM_EXCESS=0
--- a/arch/blackfin/configs/BF538-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF538-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -21,7 +21,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF538=y
CONFIG_IRQ_TIMER0=12
CONFIG_IRQ_TIMER1=12
--- a/arch/blackfin/configs/BF548-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF548-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF548_std=y
CONFIG_IRQ_TIMER0=11
# CONFIG_CYCLES_CLOCKSOURCE is not set
--- a/arch/blackfin/configs/BF561-ACVILON_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF561-ACVILON_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -20,7 +20,7 @@
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF561=y
CONFIG_BF_REV_0_5=y
CONFIG_IRQ_TIMER0=10
--- a/arch/blackfin/configs/BF561-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF561-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF561=y
CONFIG_IRQ_TIMER0=10
CONFIG_CLKIN_HZ=30000000
--- a/arch/blackfin/configs/BF561-EZKIT-SMP_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF561-EZKIT-SMP_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF561=y
CONFIG_SMP=y
CONFIG_IRQ_TIMER0=10
--- a/arch/blackfin/configs/BF609-EZKIT_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BF609-EZKIT_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -20,7 +20,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF609=y
CONFIG_PINT1_ASSIGN=0x01010000
CONFIG_PINT2_ASSIGN=0x07000101
--- a/arch/blackfin/configs/BlackStamp_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/BlackStamp_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -17,7 +17,7 @@
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF532=y
CONFIG_BF_REV_0_5=y
CONFIG_BLACKSTAMP=y
--- a/arch/blackfin/configs/CM-BF527_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/CM-BF527_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -19,7 +19,7 @@
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF527=y
CONFIG_BF_REV_0_1=y
CONFIG_IRQ_TIMER0=12
--- a/arch/blackfin/configs/PNAV-10_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/PNAV-10_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -15,7 +15,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF537=y
CONFIG_IRQ_TIMER0=12
CONFIG_PNAV10=y
--- a/arch/blackfin/configs/SRV1_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/SRV1_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -13,7 +13,7 @@
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_IOSCHED_DEADLINE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF537=y
CONFIG_IRQ_TIMER0=12
CONFIG_BOOT_LOAD=0x400000
--- a/arch/blackfin/configs/TCM-BF518_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/blackfin/configs/TCM-BF518_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -23,7 +23,7 @@
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BF518=y
CONFIG_BF_REV_0_1=y
CONFIG_BFIN518F_TCM=y
--- a/arch/mips/configs/fuloong2e_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/fuloong2e_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -2,7 +2,8 @@
CONFIG_64BIT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
CONFIG_LOCALVERSION="-fuloong2e"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
--- a/arch/mips/configs/gpr_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/gpr_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,7 +1,8 @@
CONFIG_MIPS_ALCHEMY=y
CONFIG_MIPS_GPR=y
CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
--- a/arch/mips/configs/ip22_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/ip22_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -4,7 +4,8 @@
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_1000=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
--- a/arch/mips/configs/ip28_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/ip28_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,6 +1,7 @@
CONFIG_SGI_IP28=y
CONFIG_ARC_CONSOLE=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
--- a/arch/mips/configs/jazz_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/jazz_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,6 +1,7 @@
CONFIG_MACH_JAZZ=y
CONFIG_OLIVETTI_M700=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
--- a/arch/mips/configs/mtx1_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/mtx1_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,6 +1,7 @@
CONFIG_MIPS_ALCHEMY=y
CONFIG_MIPS_MTX1=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
--- a/arch/mips/configs/nlm_xlr_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/nlm_xlr_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -5,7 +5,7 @@
CONFIG_SMP=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_KEXEC=y
CONFIG_CROSS_COMPILE=""
# CONFIG_LOCALVERSION_AUTO is not set
--- a/arch/mips/configs/pic32mzda_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/pic32mzda_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,7 +1,7 @@
CONFIG_MACH_PIC32=y
CONFIG_DTB_PIC32_MZDA_SK=y
CONFIG_HZ_100=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_SECCOMP is not set
CONFIG_SYSVIPC=y
CONFIG_NO_HZ=y
--- a/arch/mips/configs/pistachio_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/pistachio_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -5,7 +5,7 @@
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
CONFIG_ZSMALLOC=y
CONFIG_NR_CPUS=4
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="localhost"
CONFIG_SYSVIPC=y
--- a/arch/mips/configs/pnx8335_stb225_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/pnx8335_stb225_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -3,7 +3,7 @@
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_128=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_SECCOMP is not set
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
--- a/arch/mips/configs/rm200_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/mips/configs/rm200_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -2,7 +2,8 @@
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_ARC_CONSOLE=y
CONFIG_HZ_1000=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
+CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
--- a/arch/parisc/configs/712_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/parisc/configs/712_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -13,7 +13,7 @@
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_PA7100LC=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_GSC_LASI=y
# CONFIG_PDC_CHASSIS is not set
CONFIG_BINFMT_MISC=m
--- a/arch/parisc/configs/c3000_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/parisc/configs/c3000_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -13,7 +13,7 @@
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_PA8X00=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
# CONFIG_GSC is not set
CONFIG_PCI=y
CONFIG_PCI_LBA=y
--- a/arch/parisc/configs/default_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/parisc/configs/default_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -14,7 +14,7 @@
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PA7100LC=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_IOMMU_CCIO=y
CONFIG_GSC_LASI=y
CONFIG_GSC_WAX=y
--- a/arch/powerpc/configs/c2k_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/powerpc/configs/c2k_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -29,7 +29,7 @@
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_GEN_RTC=y
CONFIG_HIGHMEM=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
CONFIG_PCI_MSI=y
--- a/arch/powerpc/configs/ppc6xx_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/powerpc/configs/ppc6xx_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -74,7 +74,7 @@
CONFIG_MCU_MPC8349EMITX=y
CONFIG_HIGHMEM=y
CONFIG_HZ_1000=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_BINFMT_MISC=y
CONFIG_HIBERNATION=y
CONFIG_PM_DEBUG=y
--- a/arch/powerpc/platforms/cell/spufs/sched.c 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/powerpc/platforms/cell/spufs/sched.c 2018-02-02 18:39:26.000000000 -0500
@@ -65,11 +65,6 @@
static struct timer_list spuloadavg_timer;
/*
- * Priority of a normal, non-rt, non-niced'd process (aka nice level 0).
- */
-#define NORMAL_PRIO 120
-
-/*
* Frequency of the spu scheduler tick. By default we do one SPU scheduler
* tick for every 10 CPU scheduler ticks.
*/
--- a/arch/score/configs/spct6600_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/score/configs/spct6600_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -1,5 +1,5 @@
CONFIG_HZ_100=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SYSVIPC=y
--- a/arch/sh/configs/se7712_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/sh/configs/se7712_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -23,7 +23,7 @@
CONFIG_SH_SOLUTION_ENGINE=y
CONFIG_SH_PCLK_FREQ=66666666
CONFIG_HEARTBEAT=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_CMDLINE_OVERWRITE=y
CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda1"
CONFIG_NET=y
--- a/arch/sh/configs/se7721_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/sh/configs/se7721_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -23,7 +23,7 @@
CONFIG_SH_7721_SOLUTION_ENGINE=y
CONFIG_SH_PCLK_FREQ=33333333
CONFIG_HEARTBEAT=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_CMDLINE_OVERWRITE=y
CONFIG_CMDLINE="console=ttySC0,115200 root=/dev/sda2"
CONFIG_NET=y
--- a/arch/sh/configs/titan_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/sh/configs/titan_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -20,7 +20,7 @@
CONFIG_SH_PCLK_FREQ=30000000
CONFIG_SH_DMA=y
CONFIG_SH_DMA_API=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_CMDLINE_OVERWRITE=y
CONFIG_CMDLINE="console=ttySC1,38400N81 root=/dev/nfs ip=:::::eth1:autoconf rw"
CONFIG_PCI=y
--- a/arch/sparc/configs/sparc64_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/sparc/configs/sparc64_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -22,7 +22,7 @@
CONFIG_HIGH_RES_TIMERS=y
CONFIG_NUMA=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=8192
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_SUN_LDOMS=y
CONFIG_PCI=y
CONFIG_PCI_MSI=y
--- a/arch/tile/configs/tilegx_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/tile/configs/tilegx_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -47,7 +47,7 @@
CONFIG_NR_CPUS=100
CONFIG_HZ_100=y
# CONFIG_COMPACTION is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_TILE_PCI_IO=y
CONFIG_PCI_DEBUG=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
--- a/arch/tile/configs/tilepro_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/tile/configs/tilepro_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -44,7 +44,7 @@
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_HZ_100=y
# CONFIG_COMPACTION is not set
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_PCI_DEBUG=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=y
--- a/arch/x86/configs/i386_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/x86/configs/i386_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -41,7 +41,7 @@
CONFIG_X86_GENERIC=y
CONFIG_HPET_TIMER=y
CONFIG_SCHED_SMT=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_REBOOTFIXUPS=y
--- a/arch/x86/configs/x86_64_defconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/x86/configs/x86_64_defconfig 2018-02-02 18:39:26.000000000 -0500
@@ -40,7 +40,7 @@
CONFIG_CALGARY_IOMMU=y
CONFIG_NR_CPUS=64
CONFIG_SCHED_SMT=y
-CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_PREEMPT=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=y
--- a/arch/x86/Kconfig 2018-01-28 16:20:33.000000000 -0500
+++ b/arch/x86/Kconfig 2018-02-02 18:39:26.000000000 -0500
@@ -961,10 +961,26 @@
depends on SMP
---help---
SMT scheduler support improves the CPU scheduler's decision making
- when dealing with Intel Pentium 4 chips with HyperThreading at a
+ when dealing with Intel P4/Core 2 chips with HyperThreading at a
cost of slightly increased overhead in some places. If unsure say
N here.
+config SMT_NICE
+ bool "SMT (Hyperthreading) aware nice priority and policy support"
+ depends on SCHED_MUQSS && SCHED_SMT
+ default y
+ ---help---
+ Enabling Hyperthreading on Intel CPUs decreases the effectiveness
+ of the use of 'nice' levels and different scheduling policies
+ (e.g. realtime) due to sharing of CPU power between hyperthreads.
+ SMT nice support makes each logical CPU aware of what is running on
+ its hyperthread siblings, maintaining appropriate distribution of
+ CPU according to nice levels and scheduling policies at the expense
+ of slightly increased overhead.
+
+ If unsure say Y here.
+
+
config SCHED_MC
def_bool y
prompt "Multi-core scheduler support"
@@ -1359,7 +1375,7 @@
endchoice
choice
- prompt "Memory split" if EXPERT
+ prompt "Memory split"
default VMSPLIT_3G
depends on X86_32
---help---
@@ -1379,17 +1395,17 @@
option alone!
config VMSPLIT_3G
- bool "3G/1G user/kernel split"
+ bool "Default 896MB lowmem (3G/1G user/kernel split)"
config VMSPLIT_3G_OPT
depends on !X86_PAE
- bool "3G/1G user/kernel split (for full 1G low memory)"
+ bool "1GB lowmem (3G/1G user/kernel split)"
config VMSPLIT_2G
- bool "2G/2G user/kernel split"
+ bool "2GB lowmem (2G/2G user/kernel split)"
config VMSPLIT_2G_OPT
depends on !X86_PAE
- bool "2G/2G user/kernel split (for full 2G low memory)"
+ bool "2GB lowmem (2G/2G user/kernel split)"
config VMSPLIT_1G
- bool "1G/3G user/kernel split"
+ bool "3GB lowmem (1G/3G user/kernel split)"
endchoice
config PAGE_OFFSET
--- a/block/Kconfig.iosched 2018-01-28 16:20:33.000000000 -0500
+++ b/block/Kconfig.iosched 2018-02-02 18:39:26.000000000 -0500
@@ -82,7 +82,7 @@
config IOSCHED_BFQ
tristate "BFQ I/O scheduler"
- default n
+ default y
---help---
BFQ I/O scheduler for BLK-MQ. BFQ distributes the bandwidth of
of the device among all processes according to their weights,
--- /dev/null 2018-02-04 09:54:11.272993842 -0500
+++ b/Documentation/scheduler/sched-BFS.txt 2018-02-02 18:39:26.000000000 -0500
@@ -0,0 +1,351 @@
+BFS - The Brain Fuck Scheduler by Con Kolivas.
+
+Goals.
+
+The goal of the Brain Fuck Scheduler, referred to as BFS from here on, is to
+completely do away with the complex designs of the past for the cpu process
+scheduler and instead implement one that is very simple in basic design.
+The main focus of BFS is to achieve excellent desktop interactivity and
+responsiveness without heuristics and tuning knobs that are difficult to
+understand, impossible to model and predict the effect of, and when tuned to
+one workload cause massive detriment to another.
+
+
+Design summary.
+
+BFS is best described as a single runqueue, O(n) lookup, earliest effective
+virtual deadline first design, loosely based on EEVDF (earliest eligible virtual
+deadline first) and my previous Staircase Deadline scheduler. Each component
+shall be described in order to understand the significance of, and reasoning for
+it. The codebase when the first stable version was released was approximately
+9000 lines less code than the existing mainline linux kernel scheduler (in
+2.6.31). This does not even take into account the removal of documentation and
+the cgroups code that is not used.
+
+Design reasoning.
+
+The single runqueue refers to the queued but not running processes for the
+entire system, regardless of the number of CPUs. The reason for going back to
+a single runqueue design is that once multiple runqueues are introduced,
+per-CPU or otherwise, there will be complex interactions as each runqueue will
+be responsible for the scheduling latency and fairness of the tasks only on its
+own runqueue, and to achieve fairness and low latency across multiple CPUs, any
+advantage in throughput of having CPU local tasks causes other disadvantages.
+This is due to requiring a very complex balancing system to at best achieve some
+semblance of fairness across CPUs and can only maintain relatively low latency
+for tasks bound to the same CPUs, not across them. To increase said fairness
+and latency across CPUs, the advantage of local runqueue locking, which makes
+for better scalability, is lost due to having to grab multiple locks.
+
+A significant feature of BFS is that all accounting is done purely based on CPU
+used and nowhere is sleep time used in any way to determine entitlement or
+interactivity. Interactivity "estimators" that use some kind of sleep/run
+algorithm are doomed to fail to detect all interactive tasks, and to falsely tag
+tasks that aren't interactive as being so. The reason for this is that it is
+close to impossible to determine that when a task is sleeping, whether it is
+doing it voluntarily, as in a userspace application waiting for input in the
+form of a mouse click or otherwise, or involuntarily, because it is waiting for
+another thread, process, I/O, kernel activity or whatever. Thus, such an
+estimator will introduce corner cases, and more heuristics will be required to
+cope with those corner cases, introducing more corner cases and failed
+interactivity detection and so on. Interactivity in BFS is built into the design
+by virtue of the fact that tasks that are waking up have not used up their quota
+of CPU time, and have earlier effective deadlines, thereby making it very likely
+they will preempt any CPU bound task of equivalent nice level. See below for
+more information on the virtual deadline mechanism. Even if they do not preempt
+a running task, because the rr interval is guaranteed to have a bound upper
+limit on how long a task will wait for, it will be scheduled within a timeframe
+that will not cause visible interface jitter.
+
+
+Design details.
+
+Task insertion.
+
+BFS inserts tasks into each relevant queue as an O(1) insertion into a double
+linked list. On insertion, *every* running queue is checked to see if the newly
+queued task can run on any idle queue, or preempt the lowest running task on the
+system. This is how the cross-CPU scheduling of BFS achieves significantly lower
+latency per extra CPU the system has. In this case the lookup is, in the worst
+case scenario, O(n) where n is the number of CPUs on the system.
+
+Data protection.
+
+BFS has one single lock protecting the process local data of every task in the
+global queue. Thus every insertion, removal and modification of task data in the
+global runqueue needs to grab the global lock. However, once a task is taken by
+a CPU, the CPU has its own local data copy of the running process' accounting
+information which only that CPU accesses and modifies (such as during a
+timer tick) thus allowing the accounting data to be updated lockless. Once a
+CPU has taken a task to run, it removes it from the global queue. Thus the
+global queue only ever has, at most,
+
+ (number of tasks requesting cpu time) - (number of logical CPUs) + 1
+
+tasks in the global queue. This value is relevant for the time taken to look up
+tasks during scheduling. This will increase if many tasks with CPU affinity set
+in their policy to limit which CPUs they're allowed to run on if they outnumber
+the number of CPUs. The +1 is because when rescheduling a task, the CPU's
+currently running task is put back on the queue. Lookup will be described after
+the virtual deadline mechanism is explained.
+
+Virtual deadline.
+
+The key to achieving low latency, scheduling fairness, and "nice level"
+distribution in BFS is entirely in the virtual deadline mechanism. The one
+tunable in BFS is the rr_interval, or "round robin interval". This is the
+maximum time two SCHED_OTHER (or SCHED_NORMAL, the common scheduling policy)
+tasks of the same nice level will be running for, or looking at it the other
+way around, the longest duration two tasks of the same nice level will be
+delayed for. When a task requests cpu time, it is given a quota (time_slice)
+equal to the rr_interval and a virtual deadline. The virtual deadline is
+offset from the current time in jiffies by this equation:
+
+ jiffies + (prio_ratio * rr_interval)
+
+The prio_ratio is determined as a ratio compared to the baseline of nice -20
+and increases by 10% per nice level. The deadline is a virtual one only in that
+no guarantee is placed that a task will actually be scheduled by this time, but
+it is used to compare which task should go next. There are three components to
+how a task is next chosen. First is time_slice expiration. If a task runs out
+of its time_slice, it is descheduled, the time_slice is refilled, and the
+deadline reset to that formula above. Second is sleep, where a task no longer
+is requesting CPU for whatever reason. The time_slice and deadline are _not_
+adjusted in this case and are just carried over for when the task is next
+scheduled. Third is preemption, and that is when a newly waking task is deemed
+higher priority than a currently running task on any cpu by virtue of the fact
+that it has an earlier virtual deadline than the currently running task. The
+earlier deadline is the key to which task is next chosen for the first and
+second cases. Once a task is descheduled, it is put back on the queue, and an
+O(n) lookup of all queued-but-not-running tasks is done to determine which has
+the earliest deadline and that task is chosen to receive CPU next.
+
+The CPU proportion of different nice tasks works out to be approximately the
+
+ (prio_ratio difference)^2
+
+The reason it is squared is that a task's deadline does not change while it is
+running unless it runs out of time_slice. Thus, even if the time actually
+passes the deadline of another task that is queued, it will not get CPU time
+unless the current running task deschedules, and the time "base" (jiffies) is
+constantly moving.
+
+Task lookup.
+
+BFS has 103 priority queues. 100 of these are dedicated to the static priority
+of realtime tasks, and the remaining 3 are, in order of best to worst priority,
+SCHED_ISO (isochronous), SCHED_NORMAL, and SCHED_IDLEPRIO (idle priority
+scheduling). When a task of these priorities is queued, a bitmap of running
+priorities is set showing which of these priorities has tasks waiting for CPU
+time. When a CPU is made to reschedule, the lookup for the next task to get
+CPU time is performed in the following way:
+
+First the bitmap is checked to see what static priority tasks are queued. If
+any realtime priorities are found, the corresponding queue is checked and the
+first task listed there is taken (provided CPU affinity is suitable) and lookup
+is complete. If the priority corresponds to a SCHED_ISO task, they are also
+taken in FIFO order (as they behave like SCHED_RR). If the priority corresponds
+to either SCHED_NORMAL or SCHED_IDLEPRIO, then the lookup becomes O(n). At this
+stage, every task in the runlist that corresponds to that priority is checked
+to see which has the earliest set deadline, and (provided it has suitable CPU
+affinity) it is taken off the runqueue and given the CPU. If a task has an
+expired deadline, it is taken and the rest of the lookup aborted (as they are
+chosen in FIFO order).
+
+Thus, the lookup is O(n) in the worst case only, where n is as described
+earlier, as tasks may be chosen before the whole task list is looked over.
+
+
+Scalability.
+
+The major limitations of BFS will be that of scalability, as the separate
+runqueue designs will have less lock contention as the number of CPUs rises.
+However they do not scale linearly even with separate runqueues as multiple
+runqueues will need to be locked concurrently on such designs to be able to
+achieve fair CPU balancing, to try and achieve some sort of nice-level fairness
+across CPUs, and to achieve low enough latency for tasks on a busy CPU when
+other CPUs would be more suited. BFS has the advantage that it requires no
+balancing algorithm whatsoever, as balancing occurs by proxy simply because
+all CPUs draw off the global runqueue, in priority and deadline order. Despite
+the fact that scalability is _not_ the prime concern of BFS, it both shows very
+good scalability to smaller numbers of CPUs and is likely a more scalable design
+at these numbers of CPUs.
+
+It also has some very low overhead scalability features built into the design
+when it has been deemed their overhead is so marginal that they're worth adding.
+The first is the local copy of the running process' data to the CPU it's running
+on to allow that data to be updated lockless where possible. Then there is
+deference paid to the last CPU a task was running on, by trying that CPU first
+when looking for an idle CPU to use the next time it's scheduled. Finally there
+is the notion of cache locality beyond the last running CPU. The sched_domains
+information is used to determine the relative virtual "cache distance" that
+other CPUs have from the last CPU a task was running on. CPUs with shared
+caches, such as SMT siblings, or multicore CPUs with shared caches, are treated
+as cache local. CPUs without shared caches are treated as not cache local, and
+CPUs on different NUMA nodes are treated as very distant. This "relative cache
+distance" is used by modifying the virtual deadline value when doing lookups.
+Effectively, the deadline is unaltered between "cache local" CPUs, doubled for
+"cache distant" CPUs, and quadrupled for "very distant" CPUs. The reasoning
+behind the doubling of deadlines is as follows. The real cost of migrating a
+task from one CPU to another is entirely dependant on the cache footprint of
+the task, how cache intensive the task is, how long it's been running on that
+CPU to take up the bulk of its cache, how big the CPU cache is, how fast and
+how layered the CPU cache is, how fast a context switch is... and so on. In
+other words, it's close to random in the real world where we do more than just
+one sole workload. The only thing we can be sure of is that it's not free. So
+BFS uses the principle that an idle CPU is a wasted CPU and utilising idle CPUs
+is more important than cache locality, and cache locality only plays a part
+after that. Doubling the effective deadline is based on the premise that the
+"cache local" CPUs will tend to work on the same tasks up to double the number
+of cache local CPUs, and once the workload is beyond that amount, it is likely
+that none of the tasks are cache warm anywhere anyway. The quadrupling for NUMA
+is a value I pulled out of my arse.
+
+When choosing an idle CPU for a waking task, the cache locality is determined
+according to where the task last ran and then idle CPUs are ranked from best
+to worst to choose the most suitable idle CPU based on cache locality, NUMA
+node locality and hyperthread sibling business. They are chosen in the
+following preference (if idle):
+
+* Same core, idle or busy cache, idle threads
+* Other core, same cache, idle or busy cache, idle threads.
+* Same node, other CPU, idle cache, idle threads.
+* Same node, other CPU, busy cache, idle threads.
+* Same core, busy threads.
+* Other core, same cache, busy threads.
+* Same node, other CPU, busy threads.
+* Other node, other CPU, idle cache, idle threads.
+* Other node, other CPU, busy cache, idle threads.
+* Other node, other CPU, busy threads.
+
+This shows the SMT or "hyperthread" awareness in the design as well which will
+choose a real idle core first before a logical SMT sibling which already has
+tasks on the physical CPU.
+
+Early benchmarking of BFS suggested scalability dropped off at the 16 CPU mark.
+However this benchmarking was performed on an earlier design that was far less
+scalable than the current one so it's hard to know how scalable it is in terms
+of both CPUs (due to the global runqueue) and heavily loaded machines (due to
+O(n) lookup) at this stage. Note that in terms of scalability, the number of
+_logical_ CPUs matters, not the number of _physical_ CPUs. Thus, a dual (2x)
+quad core (4X) hyperthreaded (2X) machine is effectively a 16X. Newer benchmark
+results are very promising indeed, without needing to tweak any knobs, features
+or options. Benchmark contributions are most welcome.
+
+
+Features
+
+As the initial prime target audience for BFS was the average desktop user, it
+was designed to not need tweaking, tuning or have features set to obtain benefit
+from it. Thus the number of knobs and features has been kept to an absolute
+minimum and should not require extra user input for the vast majority of cases.
+There are precisely 2 tunables, and 2 extra scheduling policies. The rr_interval
+and iso_cpu tunables, and the SCHED_ISO and SCHED_IDLEPRIO policies. In addition
+to this, BFS also uses sub-tick accounting. What BFS does _not_ now feature is
+support for CGROUPS. The average user should neither need to know what these
+are, nor should they need to be using them to have good desktop behaviour.
+
+rr_interval
+
+There is only one "scheduler" tunable, the round robin interval. This can be
+accessed in
+
+ /proc/sys/kernel/rr_interval
+
+The value is in milliseconds, and the default value is set to 6 on a
+uniprocessor machine, and automatically set to a progressively higher value on
+multiprocessor machines. The reasoning behind increasing the value on more CPUs
+is that the effective latency is decreased by virtue of there being more CPUs on
+BFS (for reasons explained above), and increasing the value allows for less
+cache contention and more throughput. Valid values are from 1 to 1000
+Decreasing the value will decrease latencies at the cost of decreasing
+throughput, while increasing it will improve throughput, but at the cost of
+worsening latencies. The accuracy of the rr interval is limited by HZ resolution
+of the kernel configuration. Thus, the worst case latencies are usually slightly
+higher than this actual value. The default value of 6 is not an arbitrary one.
+It is based on the fact that humans can detect jitter at approximately 7ms, so
+aiming for much lower latencies is pointless under most circumstances. It is
+worth noting this fact when comparing the latency performance of BFS to other
+schedulers. Worst case latencies being higher than 7ms are far worse than
+average latencies not being in the microsecond range.
+
+Isochronous scheduling.
+
+Isochronous scheduling is a unique scheduling policy designed to provide
+near-real-time performance to unprivileged (ie non-root) users without the
+ability to starve the machine indefinitely. Isochronous tasks (which means
+"same time") are set using, for example, the schedtool application like so:
+
+ schedtool -I -e amarok
+
+This will start the audio application "amarok" as SCHED_ISO. How SCHED_ISO works
+is that it has a priority level between true realtime tasks and SCHED_NORMAL
+which would allow them to preempt all normal tasks, in a SCHED_RR fashion (ie,
+if multiple SCHED_ISO tasks are running, they purely round robin at rr_interval
+rate). However if ISO tasks run for more than a tunable finite amount of time,
+they are then demoted back to SCHED_NORMAL scheduling. This finite amount of
+time is the percentage of _total CPU_ available across the machine, configurable
+as a percentage in the following "resource handling" tunable (as opposed to a
+scheduler tunable):
+
+ /proc/sys/kernel/iso_cpu
+
+and is set to 70% by default. It is calculated over a rolling 5 second average
+Because it is the total CPU available, it means that on a multi CPU machine, it
+is possible to have an ISO task running as realtime scheduling indefinitely on
+just one CPU, as the other CPUs will be available. Setting this to 100 is the
+equivalent of giving all users SCHED_RR access and setting it to 0 removes the
+ability to run any pseudo-realtime tasks.
+
+A feature of BFS is that it detects when an application tries to obtain a
+realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
+appropriate privileges to use those policies. When it detects this, it will
+give the task SCHED_ISO policy instead. Thus it is transparent to the user.
+Because some applications constantly set their policy as well as their nice
+level, there is potential for them to undo the override specified by the user
+on the command line of setting the policy to SCHED_ISO. To counter this, once
+a task has been set to SCHED_ISO policy, it needs superuser privileges to set
+it back to SCHED_NORMAL. This will ensure the task remains ISO and all child
+processes and threads will also inherit the ISO policy.
+
+Idleprio scheduling.
+
+Idleprio scheduling is a scheduling policy designed to give out CPU to a task
+_only_ when the CPU would be otherwise idle. The idea behind this is to allow
+ultra low priority tasks to be run in the background that have virtually no
+effect on the foreground tasks. This is ideally suited to distributed computing
+clients (like setiathome, folding, mprime etc) but can also be used to start
+a video encode or so on without any slowdown of other tasks. To avoid this
+policy from grabbing shared resources and holding them indefinitely, if it
+detects a state where the task is waiting on I/O, the machine is about to
+suspend to ram and so on, it will transiently schedule them as SCHED_NORMAL. As
+per the Isochronous task management, once a task has been scheduled as IDLEPRIO,
+it cannot be put back to SCHED_NORMAL without superuser privileges. Tasks can
+be set to start as SCHED_IDLEPRIO with the schedtool command like so:
+
+ schedtool -D -e ./mprime
+
+Subtick accounting.
+
+It is surprisingly difficult to get accurate CPU accounting, and in many cases,
+the accounting is done by simply determining what is happening at the precise
+moment a timer tick fires off. This becomes increasingly inaccurate as the
+timer tick frequency (HZ) is lowered. It is possible to create an application
+which uses almost 100% CPU, yet by being descheduled at the right time, records
+zero CPU usage. While the main problem with this is that there are possible
+security implications, it is also difficult to determine how much CPU a task
+really does use. BFS tries to use the sub-tick accounting from the TSC clock,
+where possible, to determine real CPU usage. This is not entirely reliable, but
+is far more likely to produce accurate CPU usage data than the existing designs
+and will not show tasks as consuming no CPU usage when they actually are. Thus,
+the amount of CPU reported as being used by BFS will more accurately represent
+how much CPU the task itself is using (as is shown for example by the 'time'
+application), so the reported values may be quite different to other schedulers.
+Values reported as the 'load' are more prone to problems with this design, but
+per process values are closer to real usage. When comparing throughput of BFS