On 18 March 2016 at 18:02, Michal Mazurek <akf...@jasminek.net> wrote: > On 09:22:18, 18.03.16, Chris Cappuccio wrote: >> These are really rough observations. This box spawns lots of dirty >> perl processes and also lots of fping processes for monitoring. > > The next step I had planned was related to juggling processes between > cpus. Right now that code is untouched, other than removing a line > related to priority. One idea is to compare the deadline of the last > element on every queue, and balance based on that. Maybe this will > improve this use case? > > The original diff contains commented out code (grep for > CPU_INFO_ITERATOR) that prints out the queues every second. When running > tests with it I sometimes observe one cpu is 0.5-1 second behind another, > so I think this is a good next step for this scheduler. > > BFS has one shared queue for all CPUs, maybe there is a very good reason > for that, we'll see. > > > I'd like to thank everyone for all the feedback. >
Something else to consider: it would be nice if sched_bsd.c wouldn't be changed and new code would be placed in sched_bfs.c (or sched_deadline.c or whatever) and kern_sched.c would act as an interface to that code so that we could switch schedulers via a compile time option (SCHED_xxx). I think this was the intention behind splitting the code. > -- > Michal Mazurek >
