emper merge requestshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests2021-05-05T14:38:52Zhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/193[IO] remove Future affinity awareness which is done in Blockable2021-05-05T14:38:52ZFlorian Fischer[IO] remove Future affinity awareness which is done in BlockableFollowup to !191.Followup to !191.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/192[LawsScheduler] Guard Runtime::getWorkerId() with CallerEnvironment2021-05-05T14:40:41ZFlorian Schmaus[LawsScheduler] Guard Runtime::getWorkerId() with CallerEnvironmentCalling Runtime::getWorkerId() is only possible from within the
runtime, hence guard the call with CallerEnvironment.Calling Runtime::getWorkerId() is only possible from within the
runtime, hence guard the call with CallerEnvironment.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/191Set affinity on block2021-05-05T14:30:55ZFlorian SchmausSet affinity on blockhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/190[IO] add shutdown(3) support2021-08-19T12:37:21ZFlorian Fischer[IO] add shutdown(3) supportio_uring has shutdown support since Linux 5.11.io_uring has shutdown support since Linux 5.11.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/189[LAWS] Set fiber affinity *before* dispatching it, not after2021-05-04T10:16:02ZFlorian Schmaus[LAWS] Set fiber affinity *before* dispatching it, not afterhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/188[IO] set the affinity of Fibers created by the completer thread2021-05-04T11:16:09ZFlorian Fischer[IO] set the affinity of Fibers created by the completer threadThis is a followup to and supersedes !186.
1. Switch from the STL iterator based to a C-style array batched schedule interface
`template<class Iterator> schedule(Iterator begin, Iterator finish) -> schedule(Fiber** fibers, unsigne...This is a followup to and supersedes !186.
1. Switch from the STL iterator based to a C-style array batched schedule interface
`template<class Iterator> schedule(Iterator begin, Iterator finish) -> schedule(Fiber** fibers, unsigned count)`
2. Schedule Fibers from anywhere with set affinity to the AnywhereQueue and the hinted priorityQueue
3. Use the new BPS affinity aware `signalFromAnywhere` and a affinity hint stored in Future::CallbackInternal to set the affinity for Fiber created by the completer thread and scheduled to the AnywhereQueue
I want this to experiment with the IO completer and laws. To see if scheduling completions
reaped by the completer to the worker priorityQueue as well is beneficial.
Maybe the benefit of faster dispatch from priorityQueue vs AnywhereQueue is worth the laws overhead
especially in scenarios where the completer reaps a significant chunk of all completions (20 Worker eval).https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/187[Blockable] Support worker affinity in PrivateSemaphore.signalFromAnywhere()2021-05-03T10:37:26ZFlorian Schmaus[Blockable] Support worker affinity in PrivateSemaphore.signalFromAnywhere()https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/185[check-license] exclude subprojects and use year and git user.name for autofi...2021-05-03T09:03:40ZFlorian Fischer[check-license] exclude subprojects and use year and git user.name for autofixinghttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/184[WorkerSleepStrategy] call the correct implementation method2021-05-01T13:00:27ZFlorian Fischer[WorkerSleepStrategy] call the correct implementation methodhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/183Make decision how many workers to notify in Runtime2021-05-03T09:54:55ZFlorian FischerMake decision how many workers to notify in RuntimeThe decision how many workers should be notified on new work should be
made in the runtime.
This is the whole reason why `WorkerWakeupStrategies` provide `notify{One,Many,All}` functions.
This change also simplifies the logic used in `S...The decision how many workers should be notified on new work should be
made in the runtime.
This is the whole reason why `WorkerWakeupStrategies` provide `notify{One,Many,All}` functions.
This change also simplifies the logic used in `SemaphoreWorkerSleepStrategy`.
The old simply copy-pasted semaphore based implementation could then
be split up into much smaller and simpler pieces.
`SemaphoreWorkerSleepStrategy::notify{All, Many}` is could actually be faster
because it can now use the semaphores `notify_many` function instead of
calling notifyInternal multiple times.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/182[Runtime] disable worker pinning using EMPER_DISABLE_PINNING environment vari...2021-05-03T08:43:55ZFlorian Fischer[Runtime] disable worker pinning using EMPER_DISABLE_PINNING environment variablehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/181[EchoClient] don't include shutdown duration in echo duration2021-05-03T10:14:08ZFlorian Fischer[EchoClient] don't include shutdown duration in echo duration* Shutdown the client connections after the echo phase has ended.
* Send "quit\n" on the last client connection (Though it is not guarantied
that there are no more open connection because we parallelize the termination)
* Free memory a...* Shutdown the client connections after the echo phase has ended.
* Send "quit\n" on the last client connection (Though it is not guarantied
that there are no more open connection because we parallelize the termination)
* Free memory after the Runtime has terminatedhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/180[IO] provide memory to store continuation Fiber* by the caller2021-04-27T07:02:28ZFlorian Fischer[IO] provide memory to store continuation Fiber* by the callerReason for this change is that we suspect the dynamic memory allocation
in reapCompletions for the return vector to be rather costly.
We know the maximum amount of memory needed to store continuation Fiber*
at compile-time because the s...Reason for this change is that we suspect the dynamic memory allocation
in reapCompletions for the return vector to be rather costly.
We know the maximum amount of memory needed to store continuation Fiber*
at compile-time because the size of the CQs is fixed.
This allows us to pass a buffer big enough to store all possible continuation
Fiber* to reapCompletions from the caller preventing the need for
the dynamic memory allocation for the returned vector.
The caller has to ensure that the memory is free of data races.
Currently this is ensured by allocating the buffer on the stack.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/179[EchoClient] Add load-switch feature2021-04-21T17:27:22ZFlorian Schmaus[EchoClient] Add load-switch featurehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/178[io/Stats] do not try to print the globalIo stats if there are none2021-04-20T11:52:11ZFlorian Fischer[io/Stats] do not try to print the globalIo stats if there are nonehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/177[io] do not reap completions after resubmitting a PartialCompletableFuture2021-04-20T06:39:23ZFlorian Fischer[io] do not reap completions after resubmitting a PartialCompletableFutureReaping completions after resubmitting a `PartialCompletableFuture`
can lead to unbound recursion when the resubmitted Future was
again partially completed during the resubmission.
We already observed a stack overflow due to recursion f...Reaping completions after resubmitting a `PartialCompletableFuture`
can lead to unbound recursion when the resubmitted Future was
again partially completed during the resubmission.
We already observed a stack overflow due to recursion for this in
the `IncrementalCompletionTest` using completer thread with wakeup
behaviour.
Fixes #17.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/176[EchoServer] fix echo function2021-04-19T11:08:55ZFlorian Fischer[EchoServer] fix echo functionThe `break` was not in the right scope and thus exiting the echo loop immediately in the first iteration.
Apparently I am not testing my changes :/The `break` was not in the right scope and thus exiting the echo loop immediately in the first iteration.
Apparently I am not testing my changes :/https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/175[EchoServer] exit the echo server by terminate the runtime2021-04-19T10:31:07ZFlorian Fischer[EchoServer] exit the echo server by terminate the runtimeSince stats are printed in the Runtime destructor we can not simply call
exit() and have to properly terminate the Runtime.
When the echo server receives a "quit" message all active connections will
return and the Runtime will terminate ...Since stats are printed in the Runtime destructor we can not simply call
exit() and have to properly terminate the Runtime.
When the echo server receives a "quit" message all active connections will
return and the Runtime will terminate if there is no work left.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/174[EchoClient] support latency histograms2021-04-17T20:14:36ZFlorian Fischer[EchoClient] support latency histogramsHistograms can only be collected when using a fixed amount of iterations.
When the '--histogram <file>' argument is passed each Client
collects 4 time stamps (each 8 byte):
1. Before requesting the send operation
2. After requesting th...Histograms can only be collected when using a fixed amount of iterations.
When the '--histogram <file>' argument is passed each Client
collects 4 time stamps (each 8 byte):
1. Before requesting the send operation
2. After requesting the send operation
3. After getting unblocked and dispatched because the send operation finished
4. After getting unblocked and dispatched because the recv operation finished
Taking the timestamps is enabled using a template and thus does not introduce
any runtime cost if they are not used except binary size.
Before termination three latencies are calculated and written to the histogram
file as csv data for each client and each echo.
1. total_latency := (T4 - T1)
2. after_send_latency := (T4 - T2)
3. after_send_dispatch_latency := (T4 - T3)https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/173[repare-build-dir] Check for unknown meson options2021-04-16T08:13:01ZFlorian Schmaus[repare-build-dir] Check for unknown meson optionsMeson does only emit a warning if unknown options are passed. In our
case, this is always something we should take care of, because an
option we assumed we configured, had no effect.
See also https://github.com/mesonbuild/meson/pull/8658Meson does only emit a warning if unknown options are passed. In our
case, this is always something we should take care of, because an
option we assumed we configured, had no effect.
See also https://github.com/mesonbuild/meson/pull/8658