Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • E emper
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 15
    • Issues 15
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • i4i4
  • manycore
  • emper
  • Merge requests
  • !377

increase the sleep semaphore threshold

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Florian Fischer requested to merge aj46ezos/emper:inc-sleep-sem-threshold into master Apr 23, 2022
  • Overview 1
  • Commits 1
  • Pipelines 2
  • Changes 1

We currently use the semaphore of our sleep strategy very greedy. This is due to skipping the semaphore's V() operation if we are sure that it does not kill our progress guaranty.

When scheduling new work from within the runtime we skip the wakeup if we observe nobody sleeping. This is fine in terms of progress and limits the amount of atomic operations on global state to a minimum.

Using a threshold of 0 (observe nobody sleeping) however introduces a race between inserting new work and going to sleep which harm the latency when the worker goes to sleep and is not notified about the new work.

This race is common and can be observed in the pulse micro benchmark. A emper with a threshold of 0 shows high latency compared to using an io-based sleep strategy or when increasing the threshold.

$ build-release/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1721970116.425

$ build-increased-sem-threshold/eval/pulse | python -c "<calc mean"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000023942.15

$ build-pipe-release/eval/pulse | python -c "<calc mean>
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000030557.0861111

$ build-pipe-no-completer/eval/pulse | python -c "<calc mean>"
Starting pulse evaluation with pulse=1, iterations=30 and utilization=80
mean: 1000021514.1805556

I could not measure any significant overhead due to the more atomics on my 16 core machine using the fs-eval on a SSD.

$ ./eval.py -r 50 -i emper-vanilla emper-inc-sem-threshold emper-pipe emper-pipe-no-completer
...
$ ./summarize.py results/1599f44-dirty-pasture/<date>/ -f '{target}-{median} (+- {std})'
duration_time:u:
emper-vanilla-0.202106189 (+- 0.016075981812486713)
emper-inc-sem-threshold-0.2049344115 (+- 0.015348506939891596)
emper-pipe-0.21689131 (+- 0.015198438371285145)
emper-pipe-no-completer-0.1372724185 (+- 0.005865720218833998)
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: inc-sleep-sem-threshold