ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Scheduler-test: further configuration options for flexible testing

Browse source 
The next goal is to determine basic performance characteristics
of the Scheduler implementation written thus far;
to help with these investigations some added flexibility seems expedient

- the ability to define a per-job base expense
- added flexibility regarding the scheduling of dependencies

This changeset introduces configuration options
This commit is contained in:
Fischlurch 2024-01-05 22:31:42 +01:00
parent 032e4f6db5
commit 54f238c510
2 changed files with 157 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

57
tests/vault/gear/test-chain-load.hpp
View file

@ -191,7 +191,10 @@ namespace test {
const microseconds LOAD_DEFAULT_TIME = 100us; ///< default time delay produced by ComputationalLoad at `Node.weight==1`
const size_t LOAD_DEFAULT_MEM_SIZE = 1000; ///< default allocation base size used if ComputationalLoad.useAllocation
const Duration SCHEDULE_LEVEL_STEP{_uTicks(1ms)}; ///< time budget to plan for the calculation of each »time level« of jobs
const Duration SCHEDULE_NODE_STEP{Duration::NIL}; ///< additional time step to include in the plan for each job (node).
const Duration SCHEDULE_PLAN_STEP{_uTicks(100us)}; ///< time budget to reserve for each node to be planned and scheduled
const bool SCHEDULE_DEPENDENCY = false; ///< explicitly schedule a dependent job (or rely on NOTIFY)
const bool SCHEDULE_NOTIFY = true; ///< explicitly set notify dispatch time to the dependencie's start time.
inline uint
defaultConcurr()
@ -1666,7 +1669,10 @@ namespace test {
lib::UninitialisedDynBlock<ScheduleSpec> schedule_;
FrameRate levelSpeed_{1, SCHEDULE_LEVEL_STEP};
FrameRate nodeSpeed_{1, SCHEDULE_NODE_STEP};
FrameRate planSpeed_{1, SCHEDULE_PLAN_STEP};
double schedNotify_{SCHEDULE_NOTIFY? 1.0:0.0};
bool schedDepends_{SCHEDULE_DEPENDENCY};
uint blockLoadFactor_{2};
size_t chunkSize_{DEFAULT_CHUNKSIZE};
TimeVar startTime_{Time::ANYTIME};
@ -1793,13 +1799,6 @@ namespace test {
/* ===== Setter / builders for custom configuration ===== */
ScheduleCtx&&
withLevelDuration (microseconds plannedTime_per_level)
{
levelSpeed_ = FrameRate{1, Duration{_uTicks(plannedTime_per_level)}};
return move(*this);
}
ScheduleCtx&&
withPlanningStep (microseconds planningTime_per_node)
{
@ -1824,9 +1823,44 @@ namespace test {
}
ScheduleCtx&&
withJobDeadline (microseconds deadline_after_start)
withUpfrontPlanning()
{
withChunkSize (chainLoad_.size());
preRoll_ *= UPFRONT_PLANNING_BOOST;
return move(*this);
}
ScheduleCtx&&
withLevelDuration (microseconds fixedTime_per_level)
{
levelSpeed_ = FrameRate{1, Duration{_uTicks(fixedTime_per_level)}};
return move(*this);
}
ScheduleCtx&&
withBaseExpense (microseconds fixedTime_per_node)
{
nodeSpeed_ = FrameRate{1, Duration{_uTicks(fixedTime_per_node)}};
return move(*this);
}
ScheduleCtx&&
withScheduleDependency (bool explicitly)
{
schedDepends_ = explicitly;
return move(*this);
}
ScheduleCtx&&
withScheduleNotify (double degree)
{
schedNotify_ = degree;
return move(*this);
}
ScheduleCtx&&
withBaseExpense ()
{
deadline_ = deadline_after_start;
return move(*this);
}
@ -1842,10 +1876,9 @@ namespace test {
}
ScheduleCtx&&
withUpfrontPlanning()
withJobDeadline (microseconds deadline_after_start)
{
withChunkSize (chainLoad_.size());
preRoll_ *= UPFRONT_PLANNING_BOOST;
deadline_ = deadline_after_start;
return move(*this);
}

112
wiki/thinkPad.ichthyo.mm
View file

@ -107889,6 +107889,118 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704495633669" ID="ID_640045443" MODIFIED="1704495650611" TEXT="Erg&#xe4;nzungen Steuerung des Test-Setup">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1704495651940" ID="ID_1057017478" MODIFIED="1704495667220" TEXT="Bestimmung">
<node CREATED="1704495668109" ID="ID_1596167188" MODIFIED="1704495695017" TEXT="M&#xf6;glichkeiten ergeben sich aus der konkreten Konstruktion"/>
<node CREATED="1704495695581" ID="ID_1523037500" MODIFIED="1704495717221" TEXT="sie erm&#xf6;glichen Variabilit&#xe4;t zum &#xbb;Ausleuchten&#xab; der Eigenschaften"/>
</node>
<node CREATED="1704495722857" ID="ID_768184682" MODIFIED="1704495725508" TEXT="Freiheitsgrade">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704495728704" ID="ID_1784002890" MODIFIED="1704496452721" TEXT="einen Basis-Aufwand pro Node(Job) vorsehen">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704495783513" ID="ID_1373430396" MODIFIED="1704496452722" TEXT="Folge-Jobs nicht explizit sondern nur per Dependency planen">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704495961945" ID="ID_1860447724" MODIFIED="1704496452722" TEXT="Zeitpunkt f&#xfc;r Folge-Jobs nicht|teilweise|explizit beschr&#xe4;nken">
<icon BUILTIN="idea"/>
<node CREATED="1704496070203" HGAP="27" ID="ID_1489336677" MODIFIED="1704496414528" TEXT="zur Untersuchung als graduellen Parameter auslegen" VSHIFT="6">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
eigentlich w&#228;re das eine Ja/Nein-Entscheidung, aber da sie &#252;ber einen Zeit-Parameter gesteuert wird, kann man hier alles zwischen Time::ANYTIME und dem nominellen Zeitpunkt des Folge-Jobs explizit setzen; dieser Parameter hat sich <i>akzidentell aus der Implementierung</i>&#160; ergeben und wird im NOTIFY-Verb gespeichert; das vorliegen dieses Parameters ist es auch, wodurch der eigentliche explizite Trigger f&#252;r den Folge-Job wegfallen kann. Setzt man hier die nominelle Zeit ein, so wird das NOTIFY tats&#228;chlich erst zu dieser Zeit zugestellt, und das bedeutet, da&#223; auch Dependency-Ketten nach dem nominellen Schedule &#8222;getaktet&#8220; sind. Im anderen Extremfall gibt es keine Limitierung und das NOTIFY wird vom Scheduler zur n&#228;chstm&#246;glichen Gelegenheit zugestellt. Sofern allerdings die Berechnung ohnehin im Verzug ist, spielt diese Unterscheidung keine Rolle mehr (dann wird n&#228;mlich immer sofort getriggert); es k&#246;nnte aber f&#252;r zus&#228;tzlichen Flexibilit&#228;ts-Puffer sorgen, wenn ein Schedule zeitweilig zu d&#252;nn besetzt ist, denn erst dadurch k&#246;nnte der Scheduler sogar vorzeitig fertig werden.
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1704496443809" ID="ID_1582406331" MODIFIED="1704500310355" TEXT="Implementierung">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1704496455415" ID="ID_259562973" MODIFIED="1704496558458" TEXT="das macht leider der ScheduleCtx und Planugs-Job ziemlich komplex...">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
deshalb habe ich gez&#246;gert, diese M&#246;glichkeit gleich vorzusehen; letztlich aber wiegt das &#187;Ausleuchten&#171; von Verhaltensmustern im Test mehr (und ich erwarte keinen westentlichen Einflu&#223; auf die Performance)
</p>
</body>
</html></richcontent>
<icon BUILTIN="smily_bad"/>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1704496572319" ID="ID_1195771220" MODIFIED="1704498356010" TEXT="Basis-Aufwand">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1704496583222" ID="ID_1103812174" MODIFIED="1704498359764" TEXT="Builder-Parameter vorsehen">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1704498304154" ID="ID_1330026678" MODIFIED="1704498336224" TEXT="withBaseExpense &#x27fc; nodeSpeed_">
<icon BUILTIN="info"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496590349" ID="ID_55304707" MODIFIED="1704496621212" TEXT="Node-ID mit in die Zeitbestimmung geben">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1704498344371" ID="ID_33654612" MODIFIED="1704498363401" TEXT="nodeSpeed_ auf alle Schedules aufschlagen">
<icon BUILTIN="flag-pink"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496625440" ID="ID_1513875198" MODIFIED="1704496631952" TEXT="Dependency-Planung">
<icon BUILTIN="flag-yellow"/>
<node CREATED="1704496633181" ID="ID_621580292" MODIFIED="1704496661738" TEXT="flexibiliisiert den Zeitpunkt an dem der Job tats&#xe4;chlich abgegeben wird">
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496668636" ID="ID_373319632" MODIFIED="1704496700735" TEXT="er wird verz&#xf6;gert bis zum Setzen der Dependencies">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#5b280f" CREATED="1704496701638" ID="ID_1403516791" MODIFIED="1704496853419" TEXT="Gefahr: verz&#xf6;gerte Planung &#x2014; besteht nicht mehr">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das war anfangs ein erhebliches Problem, bis ich mich dazu durchgerungen hatte, den unmittelbaren Dispatch aufzugeben. Seither kann ein Job auch versp&#228;tet abgesetzt werden, und wandert dann sofort an die Spitze der Queue. Und da wir das komplette Array mit den Activity-Termen Aufrufu-&#252;bergreifend erhalten, k&#246;nnen dann eben Jobs auch &#187;schleppend&#171; abgesetzt werden. Genau das nutzen wir hier aus
</p>
</body>
</html></richcontent>
<icon BUILTIN="button_cancel"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496854338" ID="ID_828353402" MODIFIED="1704496907472" TEXT="an der Stelle pr&#xfc;fen, ob die Node schon Vorl&#xe4;ufer hat...">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496879110" ID="ID_1613607947" MODIFIED="1704496907473" TEXT="...wenn ja, kann der Nachfolge-Job komplett ausgelassen werden">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496923552" ID="ID_612925354" MODIFIED="1704496938479" TEXT="Anpassungen im ScheduleSpec (SchedulerAPI) notwendig">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704496939542" ID="ID_1389691721" MODIFIED="1704497070429" TEXT="Activity-Term nun &#xbb;on-demand&#xab; erzeugen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
bisher mu&#223;te er explizit per post() erzeugt werden &#8212; nun meint post() wirklich die &#220;bergabe an den Scheduler, und der Term wird hier nur noch erzeugt, wenn er nicht schon besteht. Dies rechtfertigt dann auch das optional&lt;ActitityTerm&gt; und wirkt so viel nat&#252;rlicher
</p>
</body>
</html></richcontent>
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704497136967" ID="ID_273051296" MODIFIED="1704497151404" TEXT="Zeitlimit im NOTIFY auf korrekte Handhabung pr&#xfc;fen">
<icon BUILTIN="flag-yellow"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1704497499531" ID="ID_1985146635" MODIFIED="1704497535951" TEXT="M&#xf6;glichkeit f&#xfc;r negatives Delta im StressTestRig pr&#xfc;fen">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node COLOR="#338800" CREATED="1704497119360" ID="ID_1584751968" MODIFIED="1704500287956" TEXT="Builder-Parameter vorsehen">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1704500223713" ID="ID_1326282155" MODIFIED="1704500283727" TEXT="withScheduleDependency &#x27fc; schedDepends_">
<icon BUILTIN="info"/>
</node>
<node COLOR="#435e98" CREATED="1704500233716" ID="ID_901591846" MODIFIED="1704500283727" TEXT="withScheduleNotify &#x27fc; schedNotify_ 0.0 ... 1.0">
<icon BUILTIN="info"/>
</node>
</node>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1702945804704" ID="ID_996535642" MODIFIED="1703423856728" TEXT="Beobachtungen aus erweiterten Testl&#xe4;ufen">
<icon BUILTIN="pencil"/>