tree 15de9347d92427dd99d7566ccfcf7a787b12dc61
parent 366bb4ab851137e669a2e7db7a45d73b39090249
author Paul Jakma <paul.jakma@hpe.com> 1456418516 +0000
committer Paul Jakma <paul@quagga.net> 1485197519 +0000

lib: track worst case # of cycles and don't allow granularity to go above

* The workqueue code at present errs towards optimising the granularity
  for throughput of queue items in runs.  This perhaps is at the cost
  of risking excessive delays at times.  Make the workqueue take
  worst-cases into account.

* thread.c: (thread_should_yield) When thread should yield, we can
  return the time taken for free, as it might be useful to caller.
  work_queue_run

* workqueue.h: (struct work_queue) Add fields for worst # of cycles,
  and (independently) worst time taken.

* workqueue.c: (work_queue_new) Worst starts high.

  (work_queue_run) Track the worst number of cycles taken, where a
  queue run had to yield before clearing out the queue.  Use this as an
  upper-bound on the granularity, so the granulity can never increase.

  Track the worst-case delay per work-queue, where it had to yield, thanks
  to the thread_should_yield return value change.  Note that "show thread
  cpu" already shows stats for the work_queue_run function, inc average and
  worst cases.

Deficiencies:

- A spurious outside delay (e.g.  process not run in ages) could cause
  'worst' to be very low in some particular invocation of a process,
  and it will stay that way for life of process.

- The whole thing of trying to calculate suitable granularities is just
  fragile and impossible to get 100% right.