<div dir="ltr">Hi Glenn, <br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
<br>
</div></div>Hi JP,<br>
<br>
If you compiled Litmus with “CONFIG_SCHED_DEBUG_TRACE” enabled, then the experiment-scripts run.py should have created a file named “trace.slog”. Can you find such a file? Take a look at the file and see if any error messages jump out at you. It might give you a hint as to what is wrong. If you can’t make heads or tails of the log file (which is completely understandable), tgz it up and post it to the mailing list (unless its tremendously big).<br></blockquote><div><br></div><div>Yes, I have the trace.slog. I've attached the one from the VM that I've used. At a high level I've noticed a couple of things that jump out at me, though I don't know if they're cause for concern:</div><div><br></div><div>1) There are hundreds of lines like the following (758 to be exact, over a 10 second run):</div><div>(rtspin/3181:170) scheduled_on = NO_CPU<br></div><div><br></div><div>2) I see roughly 500 lines like the following (the CPU number varies):</div><div>(rtspin/3180:503) linking to local CPU 2 to avoid IPI<br></div><div><br></div><div>3) On the VM only, I see about 170 instances of the following:</div><div>[gsnedf_get_nearest_available_cpu@litmus/sched_gsn_edf.c:275]: Could not find an available CPU close to P4<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If I may inquire, what x86 system do you have that has 128 physical cores? That’s pretty incredible! I don’t believe that anyone has ever run Litmus on anything with more than 64 cores. Come to think of it, some of liblitmus’s routines will break when P-EDF (and C-EDF with L1 clustering) is used on a system with more than 64 CPUs. This is a limitation of the user-space, not the Litmus kernel.<br>
<br></blockquote><div><br></div><div>This is running on top of an SGI UV100:</div><div><a href="https://www.sgi.com/products/servers/uv/">https://www.sgi.com/products/servers/uv/</a><br></div><div><br></div><div>Ours is an older generation of the machine than what I linked to. But the architecture hasn't changed that much. It's a bunch of Xeon X7550 NUMAlink providing cache coherence.</div><div><br></div><div>Once I kind of figure out what I'm doing, I'd be happy to try to run some experiments on it if you're interested. Feel free to follow up with me off-list if this is of interest to you or your group. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Here are links to the broken user-space code:<br>
<a href="https://github.com/LITMUS-RT/liblitmus/blob/master/src/migration.c#L105" target="_blank">https://github.com/LITMUS-RT/liblitmus/blob/master/src/migration.c#L105</a><br>
<a href="https://github.com/LITMUS-RT/liblitmus/blob/master/src/migration.c#L127" target="_blank">https://github.com/LITMUS-RT/liblitmus/blob/master/src/migration.c#L127</a><br>
<br>
The limitation is this: a 64-bit mask is used to report the mapping between CPU clusters (“domains”) and CPUs. If you have more than 64 CPUs or more than 64 domains, then these routines will break. You haven’t hit this limit yet since your VM is constrained to 8 cores. I must say, I didn’t think Litmus users would hit the 64-CPU limit so soon. Maybe it’s time to come up with a solution. Björn, should we use a __uint128_t, a struct, or CPU_SET? I prefer __uint128_t to keep things simple, but I admit that only buys us time. We’d have to do something else if someone wanted to run Litmus on Xeon Phi (available today), which has 244 hardware threads.<br>
<br>
-Glenn<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div><br></div></div>