[PATCH 00/10] sched: EEVDF using latency-nice

 Peter Zijlstra [this message]
 ` [PATCH 01/10] sched: Introduce latency-nice as a per-task attribute Peter Zijlstra
 ` [PATCH 02/10] sched/core: Propagate parent tasks latency requirements to the child task Peter Zijlstra
 ` [PATCH 03/10] sched: Allow sched_{get,set}attr to change latency_nice of the task Peter Zijlstra
 ` [PATCH 04/10] sched/fair: Add latency_offset Peter Zijlstra
 ` [PATCH 05/10] sched/fair: Add sched group latency support Peter Zijlstra
 ` [PATCH 06/10] sched/fair: Add avg_vruntime Peter Zijlstra
   ` Chen Yu
     ` Peter Zijlstra
       ` Chen Yu
         ` Peter Zijlstra
 ` [PATCH 07/10] sched/fair: Remove START_DEBIT Peter Zijlstra
 ` [PATCH 08/10] sched/fair: Add lag based placement Peter Zijlstra
   ` Tim Chen
 ` [PATCH 09/10] rbtree: Add rb_add_augmented_cached() helper Peter Zijlstra
 ` [PATCH 10/10] sched/fair: Implement an EEVDF like policy Peter Zijlstra
   ` Mike Galbraith
     ` Mike Galbraith
     ` Mike Galbraith
       ` Mike Galbraith
         ` Peter Zijlstra
           ` Mike Galbraith
             ` Mike Galbraith
       ` Peter Zijlstra
         ` Peter Zijlstra
           ` Peter Zijlstra
             ` Peter Zijlstra
             ` Mike Galbraith
             ` Peter Zijlstra
 ` [PATCH 00/10] sched: EEVDF using latency-nice Vincent Guittot
   ` Peter Zijlstra
 ` Shrikanth Hegde
 ` K Prateek Nayak
   ` K Prateek Nayak
 ` Pavel Machek

Hi!

Ever since looking at the latency-nice patches, I've wondered if EEVDF would
not make more sense, and I did point Vincent at some older patches I had for
that (which is here his augmented rbtree thing comes from).

Also, since I really dislike the dual tree, I also figured we could dynamically
switch between an augmented tree and not (and while I have code for that,
that's not included in this posting because with the current results I don't
think we actually need this).

Anyway, since I'm somewhat under the weather, I spend last week desperately
trying to connect a small cluster of neurons in defiance of the snot overlord
and bring back the EEVDF patches from the dark crypts where they'd been
gathering cobwebs for the past 13 odd years.

By friday they worked well enough, and this morning (because obviously I forgot
the weekend is ideal to run benchmarks) I ran a bunch of hackbenck, netperf,
tbench and sysbench -- there's a bunch of wins and losses, but nothing that
indicates a total fail.

( in fact, some of the schbench results seem to indicate EEVDF schedules a lot
  more consistent than CFS and has a bunch of latency wins )

( hackbench also doesn't show the augmented tree and generally more expensive
  pick to be a loss, in fact it shows a slight win here )


  hackbech load + cyclictest --policy other results:


			EEVDF			 CFS

		# Min Latencies: 00053
  LNICE(19)	# Avg Latencies: 04350
		# Max Latencies: 76019

		# Min Latencies: 00052		00053
  LNICE(0)	# Avg Latencies: 00690		00687
		# Max Latencies: 14145		13913

		# Min Latencies: 00019
  LNICE(-19)	# Avg Latencies: 00261
		# Max Latencies: 05642


The nice -19 numbers aren't as pretty as Vincent's, but at the end I was going
cross-eyed from staring at tree prints and I just couldn't figure out where it
was going side-ways.

There's definitely more benchmarking/tweaking to be done (0-day already
reported a stress-ng loss), but if we can pull this off we can delete a whole
much of icky heuristics code. EEVDF is a much better defined policy than what
we currently have.