<davidlt[m]>
djdelorie: it depends what that is. In general I try to keep a single job on it. The only time it's two jobs, if it's building SRPM (there is enough IOPS for that thanks to NVMe).
<djdelorie>
I was hoping to add a glibc builder trybot for upstream CICD
<davidlt[m]>
If two build jobs are cooking most likely both or one of them will crash.
<davidlt[m]>
Would that run constantly?
<djdelorie>
so worst case is like two glibcs building at once
<djdelorie>
no, only when a patch is sent to the mailing list
<davidlt[m]>
Well glibc shouldn't use too much RAM per GCC instance.
<davidlt[m]>
Wouldn't it be better to just power down kojid (frees all the jobs)?
<davidlt[m]>
That probably would have a significant impact.
<djdelorie>
if there were some way to pause it, and wait for jobs to finish, sure, but CICD needs to be fully automatic
<davidlt[m]>
Ok. Why discuss it? Why not just attempt it now for some days? :)
<davidlt[m]>
I just rolled out from the bed :)
<djdelorie>
because asking is easier than setting up all the software on the board just to watch it all crash ;-)
<davidlt[m]>
I would just avoid explicitly sending something heavy to your board :)
<djdelorie>
it's ok if it just takes longer (I bumped swap to 16M)
<djdelorie>
you would never know when it's ok to send heavy things though
<davidlt[m]>
I do bind some high priority builds to specific boards manually.
<davidlt[m]>
Yeah, running now 11 boards (only during a day until fans are replaced). I kinda want monitoring, but I don't want to waste resources on that.
<davidlt[m]>
I am for a real life test on it.
<davidlt[m]>
If we find that this has huge impact on both, modify the CI/CD trybot to do systemctl {start,stop} kojid.
<davidlt[m]>
Yes, there is a way to wait for the job to finish too.
<djdelorie>
I recall investigating that before and not finding a way to wait...
<davidlt[m]>
You could kojid disable-host, then wait until host jobs weight is down to 0.0.