IRC channel logs


back to list of logs

<damo22>it seems /usr/bin/ps corresponds to hurd/utils/ps.c
<damo22>but there is /bin/ps.procps
<solid_black>damo22: ping
<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
<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?
<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
<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
<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>or does qemu hang, not hurd?
<damo22>because distro qemu is probably old
<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
<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>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>i just used most of your flags and it didnt hang
<damo22>its compiling again
<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> - hurd
<damo22>ok i forked it myself, i will try
<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'