IRC channel logs

<damo22>it seems /usr/bin/ps corresponds to hurd/utils/ps.c

<damo22>but there is /bin/ps.procps

<solid_black>hello!

<solid_black>damo22: ping

<damo22>pong

<damo22>/usr/bin/top looks for /proc/stat and /proc/cpuinfo

<solid_black>hi! please take a look at the glib issue about CI, and respond

<solid_black> https://gitlab.gnome.org/GNOME/glib/-/issues/3135

<damo22>ive read the issue, i dont know how to prepare the runner

<solid_black>do you have a local GitLab instance that you could test it with, before your runner is connected to GNOME's one?

<damo22>no

<solid_black>it would be good if you just commented on the issue, acking what I said (that you're willing to provide the runner), mentioning that you need guidance on how to connect it

<solid_black>also maybe try to just build glib on that box and see how long it would take and post those timings

<solid_black>(thanks for doing it btw!)

<solid_black>and I'm very positively surprised to see glib maintainer being excited about this

<solid_black>I kind of expected this to be an uphill battle, and instead this feel more like walking on a red carpet :)

<damo22>ive commented

<solid_black>ACTION looks

<solid_black>thanks

<damo22>my vm is running slower than yours

<solid_black>how slower?

<damo22>im timing the compile

<damo22>it hasnt finished yet

<solid_black>I wonder whether we could use this scenario (compiling glib) to profile & optimize things

<damo22>my cpu is AMD 1600MHz but it hangs with -cpu host

<damo22>so i probably dont have sse mmx etc

<solid_black>maybe there are intermediary values for -cpu that are much faster than the default but don't hang the VM?

<solid_black>see mmx etc are important to have

<damo22>maybe

<solid_black>mine is Intel Core i7-8650U, with -cpu host

<damo22>that would be very fast

<solid_black>you could event try to bisect which cpu flag makes your vm hang

<damo22>i should probably compile qemu from source

<solid_black>why?

<solid_black>or does qemu hang, not hurd?

<damo22>because distro qemu is probably old

<solid_black>ah

<solid_black>mine is 8.1.1

<damo22>root@zam620:~# qemu-system-i386 --version

<damo22>QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)

<solid_black>that's from December 2020, not that old

<damo22>its still compiling glib

<solid_black>are you also not using kvm possibly?

<damo22>definitely using kvm

<solid_black>well, you should really really look into the cpu flags then

<damo22>is there a way to pass individual cpu flags in?

<solid_black>like -cpu +sse,+sse2

<solid_black>I think

<damo22>ok

<solid_black>try this in particular: -cpu Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check

<damo22>i dont have invtsc

<solid_black>drop it then 🙂️

<damo22>real 30m27.840s

<damo22>for meson compile

<solid_black>uhh, so about 4 times slower than mine

<solid_black>does SMP run faster yet?

<damo22>no

<damo22>its not usable

<damo22>it hangs

<damo22>but i didnt try with -cpu host

<damo22>its just using the default cpu

<damo22>i mean my development smp

<solid_black>do you have any idea how one would profile this kind of thing?

<solid_black>what goes on in the system during heavy compilation I mean

<damo22>um

<damo22>i just used most of your flags and it didnt hang

<damo22>its compiling again

<damo22>br

<damo22>brb

<youpi>damo22: -cpu host enables exactly what the host supports

<damo22>real 30m6.510s

<damo22>a little faster

<damo22>Ok: 351

<damo22>Expected Fail: 0

<damo22>Fail: 7

<damo22>Unexpected Pass: 0

<damo22>Skipped: 2

<damo22>Timeout: 6

<damo22>real 15m15.620s

<damo22>solid_black: i have the token and it seems to be running but i dont know how to trigger a build

<damo22>solid_black: can you create a fork of glib and try to connect up the ci? i think if you tag it with "Hurd" it will build on my ci

<damo22>not a git tag

<damo22>tags:

<damo22> - hurd

<damo22>ok i forked it myself, i will try

<damo22>solid_black: https://gitlab.gnome.org/zamaudio/glib/-/jobs/3190053

<almuhs>i've just confirm that hurd/procfs/process.c is which write the file /proc/PID/stat. Setting last_processor to a fixed value in process.c, the stat file shows this fixed value

<almuhs>so, the problem must be in the last_processor value read in hurd/procfs/process.c . It seems that the value that procfs are reading is not the same that proc/info.c writes

<almuhs>previously to this experiment, i set last_processor to a fixed value in proc/info.c , but procfs continued writting 0 to stat file

<almuhs>even i disabled this directive to force to take the value #ifdef HAVE_STRUCT_THREAD_SCHED_INFO_LAST_PROCESSOR

<almuhs>in procfs/process.c

<damo22>almuhs: top uses /proc/cpuinfo which is missing

<damo22><- bed

<almuhs>damo22: yes, but i'm not checking the processor using top, instead i'm reading /proc/PID/stat, where last_processor is the last 4th field

<almuhs>this file is written by hurd/procfs/process.c

<almuhs>which theorically receives the last_processor data from hurd/proc/info.c

<fury999io>can hurd implement something like bsd's linuxemu, compatibility layer for gnu/linux binaries?

<youpi>if somebody commits to maintaining it, sure!

<janneke>ACTION skips a failing test for curl-8.3.0a in guix by adding`TFLAGS=~1474'

IRC channel logs

2023-10-10.log