emper merge requestshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests2021-07-27T11:49:05Zhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/214Implement sleep strategy using the IO subsystem2021-07-27T11:49:05ZFlorian FischerImplement sleep strategy using the IO subsystemimplement a pipe based sleep strategy using the IO subsystem
# Design goals
* Wakeup either on external newWork notifications or on local IO completions
-> Sleep strategy is sound without the IO completer
* Do as less as possible in ...implement a pipe based sleep strategy using the IO subsystem
# Design goals
* Wakeup either on external newWork notifications or on local IO completions
-> Sleep strategy is sound without the IO completer
* Do as less as possible in a system saturated with work
* Pass a hint where to find new work to suspended workers
# Algorithm
```
Data:
Global:
hint pipe
sleepers count
Per worker:
dispatch hint buffer
in flight flag
Sleep:
if we have no sleep request in flight
Atomic increment sleep count
Remember that we are sleeping
Prepare read cqe from the hint pipe to dispatch hint buffer
Prevent the completer from reaping completions on this worker's IoContext
Wait until IO completions occurred
NotifyEmper(n):
if observed sleepers <= 0
return
// Determine how many we are responsible to wake
do
toWakeup = min(observed sleepers, n)
while (!CAS(sleepers, toWakeup))
write toWakeup hints to the hint pipe
NotifyAnywhere(n):
// Ensure all n notifications take effect
while (!CAS(sleepers, observed sleepers - n))
if observed sleeping <= -n
return
toWakeup = min(observed sleeping, n)
write toWakeup hints to the hint pipe
onNewWorkCompletion:
reset in flight flag
allow completer to reap completions on this IoContext
```
# Notes
* We must decrement the sleepers count on the notifier side to
prevent multiple notifiers to observe all the same amount of sleepers,
trying to wake up the same sleepers by writing to the pipe and jamming it up
with unconsumed hints and thus blocking in the notify write resulting
in a deadlock.
* The CAS loops on the notifier side are needed because decrementing
and incrementing the excess is racy: Two notifier can observe the
sum of both their excess decrement and increment to much resulting in a
broken counter.
* Add the dispatch hint code in `AbstractWorkStealingScheduler::nextFiber`.
This allows workers to check the dispatch hint after there
where no local work to execute.
This is a trade-off where we trade slower wakeup - a just awoken worker
will check for local work - against a faster dispatch hot path when
we have work to do in our local WSQ.
* The completer tread must not reap completions on the IoContexts of
sleeping workers because this introduces a race for cqes and a possible
lost wakeup if the completer consumes the completions before the worker
is actually waiting for them.
* When notifying sleeping workers from anywhere we must ensure that all
notifications take effect. This is needed for example when terminating
the runtime to prevent sleep attempt from worker thread which are
about to sleep but have not incremented the sleeper count yet.
We achieve this by always decrementing the sleeper count by the notification
count.
Thanks to Florian Schmaus <flow@cs.fau.de> for spotting bugs and suggesting
improvements.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/213[io/tests] gracefully terminate the runtime on success2021-07-07T13:45:11ZFlorian Fischer[io/tests] gracefully terminate the runtime on successThis allows the examination of stats which get printed in the Runtime
destructor.
Also remove useless stdlib includes (Why does iwyu not catch those?).This allows the examination of stats which get printed in the Runtime
destructor.
Also remove useless stdlib includes (Why does iwyu not catch those?).https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/212[IO] document and adjust tests to changes in io_uring's broken link handling2021-07-08T07:44:59ZFlorian Fischer[IO] document and adjust tests to changes in io_uring's broken link handlingUntil kernel commit [cf10960426515](https://github.com/torvalds/linux/commit/cf109604265156bb22c45e0c2aa62f53a697a3f4) `io_uring` submitted sqes in a link until it encountered an invalid one.
Now `io_uring` will catch the error on subm...Until kernel commit [cf10960426515](https://github.com/torvalds/linux/commit/cf109604265156bb22c45e0c2aa62f53a697a3f4) `io_uring` submitted sqes in a link until it encountered an invalid one.
Now `io_uring` will catch the error on submission and
will cancel all sqe's contained in the link prior to the invalid one.
Fixes #20.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/211[Runtime] use pthread_getaffinity_np to determine default worker count2021-07-05T09:17:24ZFlorian Fischer[Runtime] use pthread_getaffinity_np to determine default worker countThe value reported by `std::thread::hardware_concurrency()` can be more than the actually available CPUs for example in a container or qemu.
`pthread_getaffinity_np` fills a CPU set with all CPU a thread can be scheduled on.
Fixes #19.The value reported by `std::thread::hardware_concurrency()` can be more than the actually available CPUs for example in a container or qemu.
`pthread_getaffinity_np` fills a CPU set with all CPU a thread can be scheduled on.
Fixes #19.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/210[IO] overhaul SQPOLL support2021-12-17T11:56:03ZFlorian Fischer[IO] overhaul SQPOLL supportTwo meson options control the io_uring sqpoll feature:
* io_uring_sqpoll - enable sq polling
* io_uring_shared_poller - share the polling thread between all io_urings
Since 5.12 the IORING_SETUP_ATTACH_WQ only causes sharing of
poller t...Two meson options control the io_uring sqpoll feature:
* io_uring_sqpoll - enable sq polling
* io_uring_shared_poller - share the polling thread between all io_urings
Since 5.12 the IORING_SETUP_ATTACH_WQ only causes sharing of
poller threads not the work queues.
See: https://github.com/axboe/liburing/issues/349
When using SQPOLL the userspace has no good way to
know how many sqes the kernmel has consumed therefore we
wait for available sqes using io_uring_sqring_wait if there
was no usable sqe.
Remove the GlobalIoContext::registerLock and register all worker
io_uring eventfd reads at the beginning of the completer function.
Also register all the worker io_uring eventfds since they never change
and it hopefully reduces overhead in the global io_uring.
When 5.15 is released with the [fix failed linkchain logic path](https://lore.kernel.org/io-uring/180ec124-79b1-2274-4570-9b0d6620d512@linux.alibaba.com/T/#t)
the kernel will consume the whole broken chain and we don't need to manually invalidate not submitted sqes.
This allows SQPOLL to work for invalid chains.
Needs !248 and at least linux 5.15.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/209[gitlab-ci] Bump flowdalic/debian-testing-dev to 1.122021-06-04T09:50:55ZFlorian Schmaus[gitlab-ci] Bump flowdalic/debian-testing-dev to 1.12https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/208[Future] Fix clang-tidy issue in MadviseFuture2021-05-20T13:59:55ZFlorian Schmaus[Future] Fix clang-tidy issue in MadviseFuturehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/207Add meson option for "check anywhere queue while stealing"2021-08-02T16:41:52ZFlorian SchmausAdd meson option for "check anywhere queue while stealing"https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/206[IO] add a madvise Future2021-05-19T07:59:18ZFlorian Fischer[IO] add a madvise FutureJust because we can and may use it in the futureJust because we can and may use it in the futurehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/205Fix most llvm-12 clang-tidy warnings in IO code2021-05-18T09:28:47ZFlorian FischerFix most llvm-12 clang-tidy warnings in IO codeResults can be seen here [https://gitlab.cs.fau.de/aj46ezos/emper/-/jobs/385513](https://gitlab.cs.fau.de/aj46ezos/emper/-/jobs/385513).
The IoContext warning is legitim and should be fixed but it is solved by !201.
* Improve future m...Results can be seen here [https://gitlab.cs.fau.de/aj46ezos/emper/-/jobs/385513](https://gitlab.cs.fau.de/aj46ezos/emper/-/jobs/385513).
The IoContext warning is legitim and should be fixed but it is solved by !201.
* Improve future member types
* GlobalIoContext fix type of cqe return type (`s/uint32_t/int32_t/`)
* Some returns types
* Ignore integer to pointer cast warning
* Fix `SimpleDiskAndNetworkTest`
Thanks llvm 12 :)https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/204[Debug] maybe-uninitialized should be ignored for gcc >= 11.1.02021-05-17T17:10:29ZFlorian Fischer[Debug] maybe-uninitialized should be ignored for gcc >= 11.1.0https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/203[check-license] Do not pass --max-args to xargs2021-05-17T14:53:35ZFlorian Schmaus[check-license] Do not pass --max-args to xargsxargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, ignoring previous --max-args valuexargs: warning: options --max-args and --replace/-I/-i are mutually exclusive, ignoring previous --max-args valuehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/202GCC 11.1 fixes2021-05-17T14:53:18ZFlorian FischerGCC 11.1 fixesgcc 11.1 on my arch system complains aout to of our test:
1. `SimpleLawsTest`: that the calls to `free` does not match the allocator function `new[]`
2. `LinkFutureTest`: that the `std::array buf` used for reading is not initializedgcc 11.1 on my arch system complains aout to of our test:
1. `SimpleLawsTest`: that the calls to `free` does not match the allocator function `new[]`
2. `LinkFutureTest`: that the `std::array buf` used for reading is not initializedhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/200[CountingPrivateSemaphore] Fix assert2021-05-17T13:18:58ZFlorian Schmaus[CountingPrivateSemaphore] Fix assertAs the code comment above the assert indicates, the atomic exchange
operation may either return nullptr or a valid Context pointer. And
this is what the assert() should assert. :)
Reported-by: Florian Fischer <florian.fl.fischer@fau.de>As the code comment above the assert indicates, the atomic exchange
operation may either return nullptr or a valid Context pointer. And
this is what the assert() should assert. :)
Reported-by: Florian Fischer <florian.fl.fischer@fau.de>https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/199[gitlab-ci] Bump debian-testing-dev image to 1.102021-05-20T10:34:09ZFlorian Schmaus[gitlab-ci] Bump debian-testing-dev image to 1.10https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/198[Common] Call abort() instead of exit() in die()2021-05-11T06:32:08ZFlorian Schmaus[Common] Call abort() instead of exit() in die()Calling abort() has multiple advantages. First, it better matches the
semantic of DIE(_MSG) as it signals an abnormal process termination,
whereas exit() is a normal process termination (even though
potentially with an error exit code). ...Calling abort() has multiple advantages. First, it better matches the
semantic of DIE(_MSG) as it signals an abnormal process termination,
whereas exit() is a normal process termination (even though
potentially with an error exit code). Secondly, abort() throws
SIGABRT, which in turn triggers a coredump, hence the program's state
can be inspected afterwards.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/197Already check if fiber is runnable in scheduliing subsystem2021-05-10T08:51:22ZFlorian SchmausAlready check if fiber is runnable in scheduliing subsystemAlready check if the fiber is in-fact runnable in the scheduling
subsystem. This should not make a difference when WS scheduling is
used, but makes a difference when LAWS is used.Already check if the fiber is in-fact runnable in the scheduling
subsystem. This should not make a difference when WS scheduling is
used, but makes a difference when LAWS is used.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/196Batch dequeue from AnywhereQueue2021-05-18T09:28:07ZFlorian SchmausBatch dequeue from AnywhereQueuehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/195[LAWS/Fiber] Introduce the concept of Multi-Fiber2021-05-10T09:00:07ZFlorian Schmaus[LAWS/Fiber] Introduce the concept of Multi-FiberLAWS, and similar scheduling strategies, only need to perform
refcounting and atomic operations if the fiber was placed in multiple
ready-lists in the first place.LAWS, and similar scheduling strategies, only need to perform
refcounting and atomic operations if the fiber was placed in multiple
ready-lists in the first place.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/194[meson] propagate set_affinity_on_block2021-05-05T15:28:22ZFlorian Fischer[meson] propagate set_affinity_on_block