From f37b67f9bb57ccb8d4bd37f4450f29b8dab99b31 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 6 Jan 2024 01:44:38 +0100 Subject: [PATCH] Scheduler-test: ability to propagate solely by NOTIFY ...watching those dumps on the example Graph with excessive dependencies made blatantly clear that we're dispatching a lot of unnecessary jobs, since the actual continuation is /always/ triggered by the dependency-NOTIFY. Before the rework of NOTIFY-Handling, this was rather obscured, but now, since the NOTIFY trigger itself is also dispatched by the Scheduler, it ''must be this job'' which actually continues the calculation, since the main job ''can not pass the gate'' before the dependency notification arrives. Thus I've now added a variation to the test setup where all these duplicate jobs are simply omitted. And, as expected, the computation runs faster and with less signs of contention. Together with the other additional parameter (the base expense) we might now actually be able to narrow down on the observation of a ''expense socket'', which can then be attributed to something like an ''inherent scheduler overhead'' --- src/vault/gear/scheduler.hpp | 23 +++++- tests/vault/gear/test-chain-load.hpp | 10 ++- wiki/thinkPad.ichthyo.mm | 108 ++++++++++++++++++++------- 3 files changed, 110 insertions(+), 31 deletions(-) diff --git a/src/vault/gear/scheduler.hpp b/src/vault/gear/scheduler.hpp index 87831a401..0e3d012ac 100644 --- a/src/vault/gear/scheduler.hpp +++ b/src/vault/gear/scheduler.hpp @@ -207,6 +207,8 @@ namespace gear { ScheduleSpec linkToSuccessor (ScheduleSpec&); ScheduleSpec linkToPredecessor(ScheduleSpec&); + private: + void maybeBuildTerm(); }; @@ -544,9 +546,7 @@ namespace gear { ScheduleSpec::post() { // protect allocation // auto guard = theScheduler_->layer2_.requireGroomingTokenHere();//////////////////////////////////////TODO can we avoid that? - term_ = move( - theScheduler_->activityLang_ - .buildCalculationJob (job_, start_,death_)); + maybeBuildTerm(); //set up new schedule by retrieving the Activity-chain... theScheduler_->postChain ({term_->post(), start_ , death_ @@ -555,9 +555,24 @@ namespace gear { return move(*this); } + /** + * @internal if not done yet, then construct the Activity-Language term + * describing the schedule according to the parameters set thus far. + */ + inline void + ScheduleSpec::maybeBuildTerm() + { + if (term_) return; + term_ = move( + theScheduler_->activityLang_ + .buildCalculationJob (job_, start_,death_)); + } + inline ScheduleSpec ScheduleSpec::linkToSuccessor (ScheduleSpec& succSpec) { + this->maybeBuildTerm(); + succSpec.maybeBuildTerm(); term_->appendNotificationTo (*succSpec.term_); return move(*this); } @@ -565,6 +580,8 @@ namespace gear { inline ScheduleSpec ScheduleSpec::linkToPredecessor (ScheduleSpec& predSpec) { + predSpec.maybeBuildTerm(); + this->maybeBuildTerm(); predSpec.term_->appendNotificationTo (*term_); return move(*this); } diff --git a/tests/vault/gear/test-chain-load.hpp b/tests/vault/gear/test-chain-load.hpp index 27b168c34..4126b20cc 100644 --- a/tests/vault/gear/test-chain-load.hpp +++ b/tests/vault/gear/test-chain-load.hpp @@ -1697,9 +1697,13 @@ namespace test { schedule_[idx] = scheduler_.defineSchedule(calcJob (idx,level)) .manifestation(manID_) .startTime (jobStartTime(level, idx)) - .lifeWindow (deadline_) - .post(); - } + .lifeWindow (deadline_); + Node& n = chainLoad_.nodes_[idx]; + if (isnil (n.pred) + or schedDepends_) + schedule_[idx].post(); + }// Node with dependencies will be triggered by NOTIFY + // and thus must not necessarily be scheduled explicitly. /** Callback: define a dependency between scheduled jobs */ void diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index b74305eea..3fecb6a2e 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -107929,22 +107929,22 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + - - + + - - + + @@ -107952,14 +107952,26 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + - - + + + + + + + + + + + @@ -107971,16 +107983,35 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - - - + + - - - + + + + + + + + + + + + + +

+ anders kann ich mir das nicht erklären, denn es ist ja nun immer nur eine kleine Zahl an Einträgen in der Queue, d.h. es besteht durchaus die Gefahr, daß sich Worker schlafen legen, weil die Queue scheinbar leer ist. Tatsächlich passiert das aber nur in den Abschnitten mit geringer Parallelität (ja der Doppel-Strang wird nun nur von einem Worker bearbeitet) +

+ + + + + + + + + @@ -107989,7 +108020,23 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 + + + + + + + + + +

+ muß dann die Info über zwei Ebenen durchreichen...? +

+ + + + @@ -107998,15 +108045,6 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - - - - - - - @@ -110626,6 +110664,26 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + +

+ nachdem ich aber nur noch per NOTIFY triggere, +

+

+ ist die beobachtbare Verzögerung nun im Gegenteil oft zu kurz. +

+

+ Nur an einer Stelle mit vielen aktiven Workern, treten mal wieder 2ms auf +

+ + + + +