09:43 <martink> lava-Q: so if I have N same-type duts on a lava farm, and I'm launching a job with parallel = N, what would cause the farm to pick the parts of the job one-by-one for execution on those N duts?

09:45 <martink> basically there's no parallelism ATM

12:09 <gallo[m]> martink: If you have N idle DUTs of the same device type (DT) and submit N parallel jobs to that device type, the LAVA scheduler should ideally assign one shard to each idle DUT. However, if there's competition, like another pipeline running the same job or another project using the same DUTs, you might lose some parallelism. This is where job priority becomes important. For example, in Mesa, jobs from Marge pipelines have higher

12:09 <gallo[m]> priority than other jobs, ensuring they get queued up first whenever there’s contention.

12:25 <ins4ne> hmm

12:25 <ins4ne> Irc are still only for idle i see.

13:00 <martink> gallo[m]: thanks, that's what I'd expect. but I'm observing a sequential execution of the shards across the idling duts here. I'll spend some more time testing.

13:49 <MrCooper> eric_engestrom: "for build jobs i/o is not an issue" if only it was that simple :) way back some tests in Mesa build jobs were randomly timing out due to the runner machine being overloaded with I/O

13:51 <MrCooper> specifically, tests which used temporary files for passing data to the test process

13:51 <eric_engestrom> MrCooper: ah, I didn't know it was i/o issues, I assumed it was cpu

13:54 <bentiss> well, now that $(nproc) returns the "correct" number of CPU (allowed), I assume most automatic scripts are getting better at not scheduling too many concurent threads, and thus less pressure on the disks as well

15:08 <MrCooper> eric_engestrom: FWIW, https://gitlab.freedesktop.org/mesa/mesa/-/jobs/65633327 took 13 minutes 5 seconds

15:16 <eric_engestrom> MrCooper: thx; looks like build times are still _very_ variable :/

15:16 <eric_engestrom> (I assume this is in response to !31846)

15:17 <eric_engestrom> hmm wait that's actually in line with what I've seen

15:18 <MrCooper> yeah saw that later, carry on :)

15:18 <eric_engestrom> :P

16:07 <daniels> eric_engestrom: nice, thanks - fwiw I don’t think there’s any low-hanging fruit in debian-testing - it just happens to be the job which builds rusticl and nvk and aco

16:08 <eric_engestrom> daniels: did you mean debian-testing-asan, the one that takes crazy long right now?

16:08 <eric_engestrom> debian-testing is 12min which is a lot but reasonable given all that it builds - like you said

16:09 <daniels> I meant that one, yeah - you said it might be one to fix but I don’t see how, unless we split by API again

16:16 <eric_engestrom> yeah, there might not be a fix, I didn't look into it, I just thought I'd make a note of it

16:42 <MrCooper> it might be worth exploring how short the jobs resulting from splitting this up can be