emper merge requestshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests2021-12-22T20:45:23Zhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/300[SpuriousFutexSemaphore] futex are 32 bits on all platforms2021-12-22T20:45:23ZFlorian Fischer[SpuriousFutexSemaphore] futex are 32 bits on all platformshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/299[Common] introduce a CACHE_LINE_SIZE define2021-12-22T20:45:59ZFlorian Fischer[Common] introduce a CACHE_LINE_SIZE defineThis define will be used in future patches.This define will be used in future patches.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/298Make Scheduler within Runtime public API2021-12-22T19:54:08ZFlorian SchmausMake Scheduler within Runtime public APIhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/297properly cancel future callbacks2021-12-27T17:25:23ZFlorian Fischerproperly cancel future callbacksCurrently canceling Futures would never happen because we
issued the cancel request only with the pointer of the future.
This works more by coincidence than by design because
the PointerTags::Future tagged onto the submitted future point...Currently canceling Futures would never happen because we
issued the cancel request only with the pointer of the future.
This works more by coincidence than by design because
the PointerTags::Future tagged onto the submitted future pointer is 0.
This does not work for callbacks because they are tagged with a
PointerTags != 0 and they don't use their callback pointer rather
than the future pointer.
Fix this by exporting the tagging from IoContext::prepareFutureChain
into IoContext::createFutureTag and use this when submitting a cancel
sqe.
Warn the user that they have to manually take care of the memory safety
of the callback because we can not await the callback in Future::cancel.
Add a test case to CancelFutureTest.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/296fix Future::cancel with new Scheduler::scheduleOn(fiber, workerId)2022-01-21T14:38:12ZFlorian Fischerfix Future::cancel with new Scheduler::scheduleOn(fiber, workerId)This function is needed to deal with worker local resources: io_uring
requests for example.
Each worker now always has a MPSC inbox queue which was already used
in the laws scheduling strategy.
Fibers can be scheduled to a specific work...This function is needed to deal with worker local resources: io_uring
requests for example.
Each worker now always has a MPSC inbox queue which was already used
in the laws scheduling strategy.
Fibers can be scheduled to a specific worker using the new
`Scheduler::scheduleOn` method.
When using MPSC queues which are only accessed by a single worker we have to
ensure that work scheduled to an inbox is retrieved and handled.
Therefore a sleeping worker must be notified if work is scheduled to its
inbox.
To do so we pass a FiberHint through the Runtime's `onNewWork` notification
callbacks.
And in the runtime we decide if we have to notify a specific worker or anyone
as before.
The sleep strategies must support `notifySpecific` to allow those new inbox queues.
Our SemaphoreSleepStrategy has a naive but generic implementation which is now always
active if the used semaphore implementation does not provide `notify_specific`.
The new `SpuriousFutex2Semaphore` uses `futex_waitv(2)` introduced in linux v5.16 to support
a more efficient way to implement `notify_specific`.
This is achieved by using a second worker exclusive
futex to wake or prevent a specific worker from sleeping.
Implement `notifySpecific` for the PipeSleepStrategy by introducing a worker
exclusive state and pipe.
Fix `Future::cancel()` by submitting the cancel request on the same worker which
submitted the future to cancel.
**TODO**:
- [x] Add `notifySpecific` support to `PipeSleepStrategy`
- [x] Fix `ScheduleOnTest` using `SemaphoreSleepStrategy` generic `notifySpecific` implementation
- [x] Fix `SemaphoreSleepStrategy::notifySpecific`. The current implementation can sleep lock if all workers try to notify someone and awaiting a state change that will never happen.
- [X] Fix the sleep lock introduced when a request can not be found and thus is not canceled.
This is a kernel bug and fixes are scheduled for linux 5.17.
Fixes #31.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/293[ConcurrentNetworkEchoTest] add optional computation per echo2021-12-17T11:52:49ZFlorian Fischer[ConcurrentNetworkEchoTest] add optional computation per echoThis makes the test closer to our echoserver.
Those changes were lying around in my IO-notification bpf branch.
I see no reason to throw them away so here they are as a seperate MR.This makes the test closer to our echoserver.
Those changes were lying around in my IO-notification bpf branch.
I see no reason to throw them away so here they are as a seperate MR.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/292[qsort] fix implicit widening clang-tidy error2021-12-17T11:53:26ZFlorian Fischer[qsort] fix implicit widening clang-tidy errorhttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/291fix {RwLocked,SharedMutex}UnboundedQueues2021-12-13T12:46:25ZFlorian Fischerfix {RwLocked,SharedMutex}UnboundedQueues`SharedMutexUnboundedQueue` did not build on my system because of a missing header and using `RwLockedUnboundedQueue` deadlocks.
To ensure that our emper variants build and do not crash horrible add fast check in the CI.`SharedMutexUnboundedQueue` did not build on my system because of a missing header and using `RwLockedUnboundedQueue` deadlocks.
To ensure that our emper variants build and do not crash horrible add fast check in the CI.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/290[CI] print the number of available CPUs2021-12-17T11:54:14ZFlorian Fischer[CI] print the number of available CPUsThis gives more context when looking at failed jobs.This gives more context when looking at failed jobs.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/289Introduce waitfree work/io-stealing2021-12-10T15:40:42ZFlorian FischerIntroduce waitfree work/io-stealingWaitfree work stealing is configured with the meson option
'waitfree_work_stealing'.
The retry logic is intentionally left in the Queues and not lifted to
the scheduler to reuse the load of an unsuccessful CAS.
Consider the following p...Waitfree work stealing is configured with the meson option
'waitfree_work_stealing'.
The retry logic is intentionally left in the Queues and not lifted to
the scheduler to reuse the load of an unsuccessful CAS.
Consider the following pseudo code examples:
steal() -> bool: steal() -> res
load load
loop: if empty return EMPTY
if empty return EMPTY cas
cas return cas ? STOLEN : LOST_RACE
if not WAITFREE and not cas:
goto loop outer():
return cas ? STOLEN : LOST_RACE loop:
res = steal()
outer(): if not WAITFREE and res == LOST_RACE:
steal() goto loop
In the right example the value loaded by a possible unsuccessful CAS
can not be reused. And a loop of unsuccessful CAS' will result in
double loads.
The retries are configurable through a template variable maxRetries.
* maxRetries < 0: indefinitely retries
* maxRetries >= 0: maxRetrieshttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/288Multiple changes to improve IO stealing2021-12-09T09:47:44ZFlorian FischerMultiple changes to improve IO stealinghttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/287[gitlab-ci] Cache subprojects/packagecache2021-12-08T15:22:25ZFlorian Schmaus[gitlab-ci] Cache subprojects/packagecachehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/286[meson] set check_anywhere_queue_while_steal automatic2021-12-06T13:40:41ZFlorian Fischer[meson] set check_anywhere_queue_while_steal automaticWe introduced the `check_anywhere_queue_while_steal` configuration
as an optimization to get the IO completions reaped by the completer
faster into the normal WSQs.
But now the emper has configurations where we don't use a completer
thus...We introduced the `check_anywhere_queue_while_steal` configuration
as an optimization to get the IO completions reaped by the completer
faster into the normal WSQs.
But now the emper has configurations where we don't use a completer
thus making this optimization useless or rather harmful.
By default automatically decide the value of
`check_anywhere_queue_while_steal` based on the value of `io_completer_behavior`.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/285Fix includes (as reported by IWYU 0.17) and update CI container image2021-12-08T15:08:30ZFlorian SchmausFix includes (as reported by IWYU 0.17) and update CI container imagehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/284[io/Stats] do not record steal attempts2021-12-06T10:00:24ZFlorian Fischer[io/Stats] do not record steal attemptsRecording every steal attempt is rather excessive and we are not doing
it for normal work.
Flamegraphs have show io-stealing takes considerable more time
than normal work stealing because of the recording of steal attempts,
especially if...Recording every steal attempt is rather excessive and we are not doing
it for normal work.
Flamegraphs have show io-stealing takes considerable more time
than normal work stealing because of the recording of steal attempts,
especially if we are using atomics to aggregate them.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/282reduce test load when logging2021-12-03T12:56:07ZFlorian Fischerreduce test load when loggingI suspect some test which scale whith the number of CPUs to timeout
mostly on jenkins2.
This patch reduces the load when logging is active and increases the
load when logging is off.
Therefore our test build with debugoptimized will do l...I suspect some test which scale whith the number of CPUs to timeout
mostly on jenkins2.
This patch reduces the load when logging is active and increases the
load when logging is off.
Therefore our test build with debugoptimized will do less and hopefully
only timeout when they actually hung and the release test will do
more.
Exaple: https://gitlab.cs.fau.de/i4/manycore/emper/-/jobs/481023
Both SimpleActor and AlarmActor tests take more than 120 seconds.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/281load CQ->tail only once during lockless stealing2021-12-03T10:39:48ZFlorian Fischerload CQ->tail only once during lockless stealingCurrently we load the CQ->tail with acquire semantic to determine
if we should steal from teh victim and load it again in the actual
stealing logic which will also immediately abort if there are no
CQEs to steal.
Keep the optimization f...Currently we load the CQ->tail with acquire semantic to determine
if we should steal from teh victim and load it again in the actual
stealing logic which will also immediately abort if there are no
CQEs to steal.
Keep the optimization for the locked case.https://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/280EchoClient: improve the help message2021-12-02T15:58:00ZFlorian FischerEchoClient: improve the help messagehttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/279add concurrent BPS test2021-11-24T17:36:10ZFlorian Fischeradd concurrent BPS testThe test introduces multiple cycles of Semaphores and
a Fiber for each semaphore blocking and signaling the next.
Through work-stealing the fibers from a cycle should be spread
across different workers and thus test concurrent use of
Bin...The test introduces multiple cycles of Semaphores and
a Fiber for each semaphore blocking and signaling the next.
Through work-stealing the fibers from a cycle should be spread
across different workers and thus test concurrent use of
BinaryPrivateSemaphores.
Cycle of length 3: Sem A -> Sem B -> Sem C -> Sem A -> ...
Algorithm:
if isFirstInCycle
signal next
wait
if not isFirstInCycle
signal nexthttps://gitlab.cs.fau.de/i4/manycore/emper/-/merge_requests/278echoclient: add a state variable for debugging2021-11-24T15:00:11ZFlorian Fischerechoclient: add a state variable for debugging