[ANNOUNCE] BFS CPU scheduler v0.444 for linux-3.12

[ANNOUNCE] BFS CPU scheduler v0.444 for linux-3.12

[Con Kolivas]

This is to announce a resync and minor update of the Brain Fuck Scheduler, 
version 0.444 for the latest stable linux kernel. The main changes include a 
resync against linux kernel version 3.12 and a rewritten mechanism for coping 
with suspend to ram/disk and resume issues present in previous versions.

The patch against linux-3.12(.x) is available here:
http://ck.kolivas.org/patches/bfs/3.0/3.12/3.12-sched-bfs-444.patch

A -ck branded linux-3.12-ck2 patch is available here:
http://ck.kolivas.org/patches/3.0/3.12/3.12-ck2/

Note that the other changes in the -ck patch are trivial only and the -ck 
patch is just the latest BFS patch with the cosmetic change of the -ck suffix.

All patches available here:
http://ck.kolivas.org/patches

Code blog:
http://ck-hack.blogspot.com

Enjoy!
お楽しみください

-- 
-ck

Re: [ANNOUNCE] BFS CPU scheduler v0.444 for linux-3.12

[David Rientjes]

On Tue, 3 Dec 2013, Con Kolivas wrote:

> This is to announce a resync and minor update of the Brain Fuck Scheduler, 
> version 0.444 for the latest stable linux kernel. The main changes include a 
> resync against linux kernel version 3.12 and a rewritten mechanism for coping 
> with suspend to ram/disk and resume issues present in previous versions.
> 

Hi Con,

Any reason that BFS hardcodes CONFIG_SLUB as the only slab allocator 
allowed?  I've cc'd Pekka and Christoph and I'm sure they'd be interested 
in any reasons that CONFIG_SLAB doesn't work correctly with a different 
drop-in scheduler, or is it just that interactivity has tested better with 
slub?

Re: [ANNOUNCE] BFS CPU scheduler v0.444 for linux-3.12

[Con Kolivas]

On 10 December 2013 09:30, David Rientjes <rientjes@google.com> wrote:
> Any reason that BFS hardcodes CONFIG_SLUB as the only slab allocator
> allowed?  I've cc'd Pekka and Christoph and I'm sure they'd be interested
> in any reasons that CONFIG_SLAB doesn't work correctly with a different
> drop-in scheduler, or is it just that interactivity has tested better with
> slub?

Hi David.

Thanks, and an interesting question you have there.

To be honest it's been probably over 2 years since I hard coded SLUB
into the BFS patch and all I can recall is that it caused a crash that
was purely due to enabling SLAB that went away with SLUB when used
with BFS. Despite the possibility that BFS exposes an issue in the
kernel that may be possible with the mainline scheduler (due to BFS
being extremely good at exposing race conditions), if the problem is
never reported with mainline, it's probably of no significance to
mainline. Changes in scheduler initialisation sequence alone may be
the real reason. The same goes with the offline CPU code which had to
be drastically reworked to work properly with suspend/hibernate on
BFS.

There certainly have been cases that BFS has exposed races that have
only become apparent in mainline a long time later. Here's one I
recall reporting as a potential issue a long time ago here:
http://marc.info/?l=linux-kernel&m=130613435113919&w=2
It was instantly discounted as not a problem, yet about 6 months later
a real issue in this code showed up.

I have no idea if the CONFIG_SLAB problem falls into this category.

Regards,
Con