ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
ximion has quit [Remote host closed the connection]
ximion has joined #freedesktop
ximion has quit [Remote host closed the connection]
ximion has joined #freedesktop
scrumplex has joined #freedesktop
scrumplex_ has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #freedesktop
<mupuf>
zmike: not just you, and yesterday was particularly bad. That being said, at 5am Finnish time it is almost pleasant to use again :D
* mupuf
wonders how much of the load our instance comes from stupid AI scrapers
<mupuf>
(a lot of people have been complaining about them on mastodon, including lore)
<mupuf>
What's interesting is the latency of establishing a connection with gitlab. It literally takes over a second from finland, so I wonder if enabling http2/quick may help with this issue
<airlied>
takes me 5 seconds to receive first response
<psykose>
it already uses http2, the slowness is all in how long gitlab takes to actually send a response and not the protocol
proc1 has joined #freedesktop
procn has quit [Ping timeout: 480 seconds]
Haaninjo has joined #freedesktop
eluks has quit [Remote host closed the connection]
eluks has joined #freedesktop
<mupuf>
psykose: ack, thanks
Haaninjo has quit [Quit: Ex-Chat]
swatish2 has joined #freedesktop
ximion has quit [Remote host closed the connection]
sima has joined #freedesktop
kasper93 has quit [Ping timeout: 480 seconds]
i-garrison has quit []
i-garrison has joined #freedesktop
tzimmermann has joined #freedesktop
jsa has joined #freedesktop
Kayden has joined #freedesktop
<bentiss>
alright, gitlab is slow apparently (as reported here), so let's try to make it faster with an update :)
<bentiss>
working on upgrading to 17.4.1 in a few minutes
<bentiss>
FWIW, migration is still not finished, but the webservice pods and everything else is ready. I guess this version is compatible with 17.3.x, but it'll definitely be better once the migration is done
<bentiss>
and migration is done. Welcome to gitlab 17.4.1
<bentiss>
and done. Please shout if you rather enforce the expiration date
AbleBacon has quit [Read error: Connection reset by peer]
mripard has joined #freedesktop
<emersion>
+1 for not enforcing
<mupuf>
+1 here too
<bentiss>
3 people showed up (included the one dropping the request), 3 are for, therefore the motion is accepted :)
<DragoonAethis>
+1 for not enforcing too
Kayden has quit [Read error: Connection reset by peer]
K`den has joined #freedesktop
K`den has quit []
K`den has joined #freedesktop
K`den is now known as Kayden
kasper93 has joined #freedesktop
lynxeye has joined #freedesktop
jsa1 has joined #freedesktop
jsa has quit [Ping timeout: 480 seconds]
<bentiss>
sigh, it seems I can not reuse the same gitlab runner token on the same machine for splitting the runner per proc... So I'll have to generate 8 tokens for each runner (actually 5 for arms and 16 for x86)
plutuniun has joined #freedesktop
plutuniun has quit [Remote host closed the connection]
plutuniun has joined #freedesktop
jsa1 has quit [Ping timeout: 480 seconds]
plutoniun has quit [Ping timeout: 480 seconds]
<bentiss>
damn, the m3l runners actually have 32 cores, but hyperthreading is now disabled
<plutuniun>
that's bullshit
<plutuniun>
faek markeing fasle hearsay
<plutuniun>
barely keeping up with 4 core mobile chipsets
<plutuniun>
behind Samsung and behind Qualcomm
<plutuniun>
^ "Apple M3 Pro Chip Has 25% Less Memory Bandwidth Than M1/M2 Pro"
<plutuniun>
M1 Ultra is inferior to common Atom CPUs
<plutuniun>
P####B models are designed for base transceiver stations, especially that for 5G networks. All other models are designed for communications (extended temperature range).
<plutuniun>
the Apple CPUs throttle down quickly and behave like mobile phones
<plutuniun>
Atom 24 real cores with real 24/7 throughput on full load
<plutuniun>
AMD and Intel are x86 with an entirely different class mich higher performance of delivered throughput with sustained capacity.. no comparison
<plutuniun>
Amd laptops > Intel laptops >> Apple laptops
<plutuniun>
the newest Apple M4 CPU has only 4 performance cores
<plutuniun>
for a total of 10 cores (6 efficiency)
<plutuniun>
the Atom line up shown is 2020, Apple M4 is 2024 spring newest most modern
<plutuniun>
G5 cellular stations can pass thousands of clients throughput data (industrial tech), M4 can keep up with 1 consumer laptop on.. personal low power models with throttling and multimedia but not performance compute (consumer tech)
<plutuniun>
current high performance desktops are 16 cores for now (with dual threads per core) for 1S16C32T setup, and the threadripper ryzen series are doubling that and maxing at 96 and 192 cores
<bentiss>
daniels: so I've restricted to 5 runners of 16 cores each for arm runners, and 4 runners of 8 cores each on m3l-30 (in replacement of m3l-29). Not sure if you prefer 8 runners of 4 cores or 4 runners of 8 cores
<daniels>
bentiss: wow nice, thanks!
<daniels>
I think I would prefer 8x8 though, given that's what we had before :P
<bentiss>
daniels: well, we only see 32 cores now
<bentiss>
or I can overlap the runners with one another
<bentiss>
unless there is a magical boot cmdline argument to re-enable hyperthreading (or whetever it's called on AMD Epyc)
todi has joined #freedesktop
<bentiss>
maybe it's disabled in the BIOS for this machine, let me spin up one other
<daniels>
urgh
todi_away has quit [Ping timeout: 480 seconds]
<bentiss>
damn, m3l-31 also sees 32 cpus only... anyway lunch time for me, will check later
<MrCooper>
should be SMT
<MrCooper>
4 "real" cores is probably closer than 8 to "4 real + 4 sibling" cores?
<bentiss>
FWIW, the issue was indeed in the BIOS, SMT was simply disabled. So redeploying the couple of runners I introduced with the correct number of cpus
<emersion>
sima: hm i was asking about drm_fourcc.h changes not going through review by the rest of the community
<emersion>
in your DMs, last discussion
<sima>
ah right
<sima>
I guess should correct that to "I do care, but it's messy, and pragmatically not caring that much seems best"
<sima>
but yeah that mr thread for printing amd modifiers is ... really silly
<sima>
MrCooper, from my intel experience defacto sob forging does happen and is super annoying
<sima>
legally a non-issue since it's all the same company, but it is a total pain for review
<sima>
I do generally complain in private though for both the intel and non-intel cases that I've seen
todi_away has joined #freedesktop
todi has quit [Ping timeout: 480 seconds]
jturney has quit [Ping timeout: 480 seconds]
<MrCooper>
sima: he's saying it's fraud if the person who wrote the change is listed as Git commit author, if they "don't understand the code"
<sima>
yeah it's defo not the best way to put this, and it doesn't look good if random non-amd folks read it
AbleBacon has joined #freedesktop
<sima>
so at most I'd maybe ping agd5f that this is better done in private and drop the usual offer to pull airlied or me (or linus) in if the message is not understood
<sima>
since otoh it's amd internals to figure this out
<MrCooper>
this is as far as I'm willing to go
<agd5f>
yes, it's an internal disagreement and it's being handled
<sima>
I mean if it's for another team then yes it'd need a bit more visible response, or when it's more in a shared space
Haaninjo has joined #freedesktop
<kbingham>
are runners blocked? I've been waiting quite a long time for the libcamera jobs to run ... but normally they start 'instantly'.
<bentiss>
kbingham: currently switching the runner to a more constraint environment, so we only have 2 available ATM
<kbingham>
Aha - that'll explain it then ;-) thanks.
<bentiss>
yeah, sorry, but in the end once you get a slot you'll be guaranteed to have 8 cpus (but not more :-P)
<kbingham>
how many runners are there normally ?
<kbingham>
Is it worth me running a gitlab-runner service locally on my build machine here to help with the libcamera jobs ?
jsa has quit [Ping timeout: 480 seconds]
<bentiss>
we have normally 3 runners, each having 8 slots of 8 cpus
<bentiss>
if you want to join the fun, that would be appreciated :)
<bentiss>
alright, m3l-30 is back in business
<mupuf>
bentiss: \o/
<mupuf>
bentiss: will we get double the runner counts, since you've enabled HT?
<bentiss>
mupuf: in the end we'll get 8*3 runners with 8 procs each for x86, so same thing than previously except that a single runner is split into 8, each of them having a different cpu_set
<bentiss>
which also makes it easier to look for who is using the CPU, because you see that in htop directly :)
<mupuf>
That's gonna be fantastic for predictible runtimes!
<bentiss>
not so much for the clutter in the runner UI :)
<bentiss>
one thing we might want to do for predictable runtime is also limitting the memory
<bentiss>
not sure if we need this though
<bentiss>
but in the end the most important is that now, a ninja run or a make -j$(nproc) will be contained into 8 cores, meaning that the runners shouldn't be on their knees 50% of the time
<bentiss>
one difference also now: we used to have 2 docker runners, 1 podman, now all 3 are using podman (because the podman one seemed to behave properly)
jsa1 has joined #freedesktop
tzimmermann has quit [Quit: Leaving]
jsa1 has quit [Ping timeout: 480 seconds]
<mupuf>
Great to hear the podman weirdness has been resoved
<daniels>
bentiss: maybe we limit the memory to 1/4 or at least 1/3?
<bentiss>
daniels: feel free to play with the config manually, and report the results :)
<bentiss>
I'll put the results in the script, but for now I've got a few urgent upstream matter to handle
<daniels>
yeah, I’m not going to be able to do anything on it this week I’m afraid
<daniels>
thankyou so much
<bentiss>
heh, I understand ;)
<bentiss>
and no worries. This was bugging us for too long. Good thing we had plumbers and that "holly shit, we really need to do somthing about it!"
jturney has joined #freedesktop
plutuniun has quit [Remote host closed the connection]
<alanc>
could probably make that site http only now that it's a read-only archive of stuff that should all have been moved to gitlab now and disable all bugzilla logins
___nick___ has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<alanc>
(making all the old bugzilla links redirect to the replacement gitlab issues would be awesome, but likely tons of work to setup)
___nick___ has joined #freedesktop
plutuniom has joined #freedesktop
agd5f_ has joined #freedesktop
<mupuf>
alanc: it wouldn't be tons of work, most of the transition was automated. It would just have been a ton of churn
<mupuf>
we settled on keeping a read-only copy
<alanc>
which isn't actually working, even if you accept the expired certificate, it just gives 500 Internal Server Error pages
<alanc>
which I assumed was more fallout of the portland state infrastructure failures
<alanc>
jrayhawk: I think for the past week, I don't remember exactly
<alanc>
I don't look at it that often - mainly when something like an old commit has a link to a bug that was there - and if I had a mapping to the replacement bug id in gitlab, I'd happily look at that instead