06:49 <bentiss> daniels: looks like I found out what we can do to restrict the numbers of cpus for a job: https://dockerlabs.collabnix.com/advanced/security/cgroups/ -> basically instead of saying we have 1 runner with a limit of 8 concurrent, we need to create 8 runners, each of them has a dedicated set of cpus (0-7, 8-15, etc...). This way, nproc sees only 8 cpus and we are guaranteed to not

06:49 <bentiss> leak that information

06:54 <mupuf> bentiss: fantastic!

07:09 <kode54> are you rolling your own runner tech?

07:26 <bentiss> kode54: ???

07:26 <kode54> sorry

07:27 <kode54> I was under the mistaken impression that such an oversight would have been considered at the outset by some runner/container tech

07:28 <bentiss> kode54: no need to apologize, I was just not sure what you meant

07:29 <bentiss> kode54: the cpus argument from docker now works, but the job still sees the 64 cpus, which means it tends to create 64 jobs when running make. I just realized that we can assign cpus to a pod, and with a small loop, we can split the load

07:30 <kode54> oh

07:31 <kode54> so you were invoking Docker incorrectly for what you wanted, and needed to learn a workaround

07:31 <kode54> (not that I knew this either)

07:31 <bentiss> we were just using the gitlab-runner docker, but without parameters

07:31 <kode54> cgroups does what you need? awesome

07:32 <kode54> glad you got that sorted, then

07:32 <bentiss> yeah

07:32 <bentiss> now I "just" need to write the configuration script and re-deploy the runners

07:32 <bentiss> not sure I'll get to it today

08:37 <MrCooper> cool stuff, anyway

12:27 <eric_engestrom> mupuf, jenatali: I think it might be that there's a missing `- !reference [.common-rules, rules]` in one of the windows overrides

12:45 <eric_engestrom> mupuf, jenatali: yeah, I'm not 100% sure (I still need to test) but I think this should fix it: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31390

12:46 <eric_engestrom> (posting it already because at least I'm 100% confident this MR can't do anything bad)

13:25 <mupuf> eric_engestrom: oh, thanks!

14:37 <mupuf> daniels: I'm upgrading the kernel for the a750 to 6.11, and I managed to boot an upstream kernel without any firmware built-in. Instead, the firmware files (~20 MB) are packaged an extra initrd. Any idea where I could store this initrd since not all of them are in linux-firmware?

14:39 <mupuf> This split will allow upreving the kernel using generic kernels such as b2c's or gfx-ci/linux

14:40 <mupuf> So far, my best proposal would be in a wiki page of b2c... but maybe a package in.gfx-ci/linux?

14:41 <daniels> a wiki page?

14:41 <daniels> I was going to say, if you built the kernel out of gfx-ci/linux then you could just upload the initramfs next to the kernel uploaded from there

14:42 <daniels> but if you're building out of random external source trees and hosting it externally, then you could just host the initramfs in the same place, built however the kernel is built

14:47 <mupuf> My goal would be first to use a generic b2c kernel... which is upstream with a couple of serial patches I need to upstream

14:49 <mupuf> My issue with the current way we build kernels is having the config hand modified and updated periodically. It makes it hard to know what was defconfig and what was meant

14:49 <daniels> I'm just kinda confused as to why we'd tie together random external kernels with an initramfs from a different kernel tree?

14:50 <mupuf> Oh, right! The reason is simple, the initrd ONLY contains firmware files

14:50 <mupuf> So, view it as an overlay

14:51 <mupuf> Linux can have many initrds appended to one another

14:51 <daniels> I guess you're also looking at a different kernel tree, because gfx-ci/linux doesn't contain bits from defconfig :\

14:51 <mupuf> And they will all get extracted in order

14:51 <mupuf> Hmm... then things may have changed!

14:52 <mupuf> Sorry for the noise then

14:52 <daniels> it's been that way since literally the first commit :P

14:52 <daniels> .gitlab-ci/build.sh will apply the defconfig used for the platform, then apply kernel/configs/mesa3d-ci_${ARCH}.config as overrides

14:52 <mupuf> ??? Didn't I create this repo? 🤣

14:53 <daniels> and the latter only contains stuff that a) isn't in the upstream defconfig, and b) is required to run on our devices

14:53 <mupuf> Am I becoming senile? 🫣

14:53 <daniels> lol, what

14:53 <daniels> are you saying that you don't want to use gfx-ci/linux because you don't like the way you did gfx-ci/linux, but isn't the way gfx-ci/linux does things?

14:54 <mupuf> YES! That's indeed what I said, and I get the irony. I didn't mean it can't be fixed, it's just making less sense right now for me to maintain two kernels

14:55 <mupuf> Hence why I maintain the b2c one which I also use for the ci gateways

14:56 <mupuf> That's when I hit the need for multiple configs

14:56 <daniels> well I have the perfect kernel tree for you!

14:56 <mupuf> Ha ha 😅

14:57 <zmike> mupuf: I'll bring a rocking chair and an extra warm sweater to xdc for you

14:57 <mupuf> Alright, I'll take another look at it and see if I can contribute back my config builder.

14:58 <zmike> we'll put you off in a corner where you can get your rest without being disturbed

14:58 <mupuf> zmike: great, I already bought the tea! Thanks 🤣

16:00 <zmike> is it just me or is gitlab slower than usual the past few days