From a46449d5aca76e0cf70328a762c8b3229a1278e2 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 18 Apr 2024 01:38:36 +0200 Subject: [PATCH] Scheduler-test: stable-state run > 1sec This test completes the stress-testing effort and summarises the findings * Scheduler performs within relevant parameter range without significant overhead * Scheduler can operate with full load in stable state, with 100% correct result --- tests/vault/gear/scheduler-stress-test.cpp | 42 +++++ wiki/thinkPad.ichthyo.mm | 175 +++++++++++++-------- 2 files changed, 150 insertions(+), 67 deletions(-) diff --git a/tests/vault/gear/scheduler-stress-test.cpp b/tests/vault/gear/scheduler-stress-test.cpp index 2cd62c08a..95cf857fe 100644 --- a/tests/vault/gear/scheduler-stress-test.cpp +++ b/tests/vault/gear/scheduler-stress-test.cpp @@ -515,6 +515,48 @@ cout << "time="< testLoad{1024}; + testLoad.seedingRule(testLoad.rule().probability(0.6).maxVal(2)) + .pruningRule(testLoad.rule().probability(0.44)) + .weightRule(testLoad.value(1)) + .setSeed(60) + .buildTopology() +// .printTopologyDOT() +// .printTopologyStatistics() + ; + size_t expectedHash = testLoad.getHash(); + + TRANSIENTLY(work::Config::COMPUTATION_CAPACITY) = 4; + BlockFlowAlloc bFlow; + EngineObserver watch; + Scheduler scheduler{bFlow, watch}; + + auto testSetup = + testLoad.setupSchedule(scheduler) + .withLoadTimeBase(5ms) + .withJobDeadline(50ms) // ◁───────────────────── deadline is way shorter than overall run time + .withChunkSize(32) // ◁───────────────────── planning of the next 32 nodes interleaved with performance + .withInstrumentation() + .withAdaptedSchedule (1.0, 4); // ◁───────────────────── stress factor 1.0 and 4 workers + double runTime = testSetup.launch_and_wait(); + auto stat = testSetup.getInvocationStatistic(); + +SHOW_EXPR(runTime) +SHOW_EXPR(stat.activeTime); +SHOW_EXPR(stat.coveredTime); +SHOW_EXPR(stat.activationCnt); +SHOW_EXPR(stat.avgConcurrency); +SHOW_EXPR(expectedHash) +SHOW_EXPR(testLoad.getHash()); + CHECK (stat.activationCnt == 1024); + CHECK (expectedHash == testLoad.getHash()); + CHECK (3.2 < stat.avgConcurrency); + CHECK (stat.coveredTime < 5 * time*1000); } }; diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 8cb05aa00..374083950 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -96143,10 +96143,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + - - + + @@ -96203,9 +96203,33 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + +

+ Fazit: ist direkt nicht möglich +

+ + + + + + + + + + + + + - - + + + + + + @@ -96217,20 +96241,23 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - - - + + + + + + + - + - - + + @@ -111045,9 +111072,22 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + + + + + + + + + + + + + - + @@ -111058,7 +111098,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -111207,8 +111248,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + + @@ -111946,8 +111988,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + @@ -115206,8 +115248,8 @@ std::cout << tmpl.render({"what", "World"}) << s - - + + @@ -115240,8 +115282,8 @@ std::cout << tmpl.render({"what", "World"}) << s - - + + @@ -115453,9 +115495,8 @@ std::cout << tmpl.render({"what", "World"}) << s - - - + + @@ -116247,20 +116288,21 @@ std::cout << tmpl.render({"what", "World"}) << s - + - - + + + - + + - @@ -116356,9 +116398,7 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

es ist und bleibt ein Kompromiß.... @@ -116367,8 +116407,7 @@ std::cout << tmpl.render({"what", "World"}) << s Ich versuche hier, eine sehr spezifische Meßmethode halbwegs generisch nutzbar zu machen, stecke dabei aber bereits gefährlich viel Vorannahmen über den Scheduler in den Meßprozeß

- - + @@ -116468,16 +116507,13 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

extent-family.hpp:356

- - + @@ -116776,29 +116812,23 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

...ich muß auch daran denken, daß nicht jede Maschine 8 Kerne hat. Insofern erscheint es sinnvoller, die Concurrency auf 4 zu beschränken, und dann zu sehen, wo man landet

- - + - - - +

der Graph-3 hat denn doch immer wieder mehrstufige Dependency-Tries — und ich kann daher nicht entscheiden, ob die beobachtete ∅concurrency = 5.4 auf dependency-wait zurückzuführen ist, oder tatsächlich durch Abregeln der Kapazität durch den Scheduler zustande kam. Möglicherweise auch beides im Wechselspiel.

- - + @@ -116811,16 +116841,13 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

das ist ziemlich gut

- - + @@ -116834,35 +116861,48 @@ std::cout << tmpl.render({"what", "World"}) << s - - - +

...da die tatsächliche Last ehr bei 5.5ms liegt, können diese Durchschnittswerte nur erklärt werden, indem zeitweilig die zusätzlichen, freien Worker mithelfen; sie können aber nicht permanent voll ausgelastet werden, da der Graph eigentlich nicht so viel Last hergibt. Trotzdem ergibt sich noch ein auf 60% verdichtetes Schedule

- - + - - - +

Das deutet alles darauf hin, daß das Scheduling weitgehend effizient  ist

- - + + + + + +

+ Abschließender Test: Laufzeit > 1 sec +

+ + + + + + + + + + + + @@ -117273,7 +117313,8 @@ std::cout << tmpl.render({"what", "World"}) << s - + +