00:20:17 <runxiyu> Is there any support for io_uring in linuxlator?
01:01:17 <kerneldove> looks nice V_PauAmma_V
01:06:25 <kerneldove> are all of the 'page' category infos in man vmstat referring to swap paging? like even flt/page faults?
01:22:40 <kerneldove> in vmstat procs section, what does b mean? man page says blocked for resources, so does that mean the process wants to run but can't because another part of the system is bogged down?
03:08:41 <ketas> i wonder if w could also be updated to avoid cursed hacks like env LC_TIME=de_DE.ISO8859-15 uptime
03:16:50 <ketas> while this is like adding hell to hell:
03:16:52 <ketas> env LANG=de_DE.ISO8859-15 uptime --libxo=json
03:17:22 <ketas> "load-average-15": 0,47
03:18:05 <ketas> endless joy
03:22:28 <ketas> i'm surprised xo even outputs that
03:23:17 <ketas> but it's piece-oriented lib and it outputs whatever you wish
03:24:47 <ketas> i recall ps just went 24h clock
03:25:28 <ketas> i guess noone complained either about ps being in "military" time
03:27:59 <ketas> i can recall number of times the locales and charsets making my life hell :p
04:14:55 <kerneldove> so i take it there's no way to make vmstat not repeat the headings every page or so? linux vmstat has an option for that why do we always get left out
04:23:59 <ketas> kerneldove: i wonder what's exec overhead
04:25:38 <ketas> vmstat queries the kernel
04:25:53 <ketas> so if vmstat is cached already
04:26:07 <kerneldove> dunno?
04:26:10 <ketas> but broken json is bug
04:27:07 <ketas> i bet if you are streaming vmstat every 1s then it should be looped within that program
04:27:43 <ketas> yeah i don't know what's overhead of executing binary
04:27:59 <ketas> i don't even know how it works actually
04:28:34 <ketas> all the hardware and internals are too hard to learn
04:28:41 <ketas> somehow
04:29:17 <ketas> also where's that stats going?
04:29:21 <kerneldove> i'm running vmstat once then parsing its output. just too bad i now have to detect when it's randomly a heading line instead of another data line. linux vmstat doesn't have that problem
04:29:28 <ketas> that's some test setup?
04:29:37 <kerneldove> system monitoring
04:30:02 <kerneldove> i'm ingesting everything significant the collating it in my mgmt platform
04:30:03 <ketas> every second?
04:30:05 <kerneldove> nah
04:30:16 <kerneldove> every 15s
04:30:34 <ketas> still high, what's the usecase?
04:30:56 <ketas> it's fast changing data for sure but
04:31:01 <kerneldove> optimize workload. basically trying to get every drop of perf out of hardware i can
04:31:07 <ketas> hmm
04:31:28 <kerneldove> ya 15s is as frequent as i'll go. might up it to 60s, but for now 15 is where i'll start
04:31:32 <ketas> what are those machines doing?
04:31:45 <kerneldove> running network services
04:35:04 <ketas> i wonder if i'm able to fix xo on my own
04:35:12 <ketas> there
04:35:15 <kerneldove> i bet you can
04:35:20 <kerneldove> i was looking at the vmstat.c today
04:35:28 <ketas> but i hate that style
04:36:02 <kerneldove> https://cgit.freebsd.org/src/tree/usr.bin/vmstat/vmstat.c#n756 see that?
04:36:29 <ketas> if library functions are built like that, no wonder dev can't see what (s)he's doing
04:37:09 <ketas> oh god
04:37:15 <ketas> why did i even look
04:37:23 <kerneldove> if you detect that multiple displays will take place, then above that line you run xo_open_container("display");, and same for close at end of the set of display objs
04:37:29 <kerneldove> you don't know c?
04:43:39 <ketas> more like xo book is missing in my head
04:43:51 <ketas> more than c book
04:44:45 <ketas> xo_close_container("processes"); xo_close_container("vmstat");
04:44:51 <ketas> missing after a loop
04:45:08 <ketas> and it needs to start again
04:45:21 <ketas> basically you can fix it by
04:45:37 <ketas> changing things so it works if runs==1
04:45:47 <ketas> or runs==inf
04:46:13 <ketas> i don't see where this even starts
04:47:44 <ketas> but somewhere it does
04:48:31 <ketas> if you do it all, both single and multi runs are correct
04:54:43 <ketas> how about we move xo open con cmstat into dovmstat
04:54:54 <ketas> and close too
04:55:44 <ketas> wait it's wrong
04:56:56 <ketas> but vmstat open/close is in main() and that's bad
04:59:19 <ketas> if (reps > 1) { xo_close_container("vmstat"); xo_open_container("vmstat"); }
04:59:29 <ketas> i hate it all
05:03:21 <ketas> dointr needs it too
05:05:45 <ketas> i can't understand anything anymore
05:06:00 <kerneldove> why not?
05:06:49 <ketas> somewhere there whole vmstat needs to close and reopen
05:06:56 <ketas> how, no idea
05:07:40 <ketas> and text mode needs to stay functional too
05:07:42 <kerneldove> start by wrapping the display set in a "display" open and close container. then add a gate around those containers based on whether or not there's gonna be multiple displays
05:08:17 <ketas> text mode runs headers every screenful
05:09:21 <ketas> yeah but i'm already tired of that
05:10:29 <ketas> oh and if you that, everyone's parser breaks
05:13:15 <ketas> if (reps >= 0 && --reps <= 0) break;
05:13:29 <ketas> here loop breaks if only one run
05:13:51 <ketas> maybe put else here to repeat the close open
05:14:21 <ketas> i bet everything that uses xo is filled with such bugs
05:17:05 <ketas> it was simply missed that in loop, it can print the middle part again
05:18:10 <ketas> and if somebody uses vmstat 1 --libxo=json
05:18:26 <ketas> this fix breaks their parser hack
05:22:51 <ketas> oh and how to fix the padding without breaking text?
05:27:48 <ketas> maybe i would be better at putting -s into w.c while it's argv0==uptime
05:28:19 <ketas> sadly w once had -s
05:39:04 <ketas> or i can keep doing variant of time="`date +%s`"; boottime="`sysctl -n kern.boottime | cut -d , -f 1 | cut -d ' ' -f 4`"; uptime="$(($time - $boottime))"
12:08:58 <cyric> ketas: w was imported back in 1994 with '-s is no longer supported'
12:09:26 <cyric> so i wouldn't say it did ever :)
12:09:36 <ketas> what did that ever do?
12:09:42 <cyric> no idea
12:09:43 <ketas> before 94
15:28:11 <mosaid> Look like after deep search that even shrinking methods is impossible in my situation :(
15:33:50 <mosaid> Only solution is having a third hard drive to dump /, then recreate the partition smaller, I will do it when I connect my drive
15:34:33 <mosaid> In april; bec. the next months I will be so busy
18:31:07 <darwin> what's the proper way to UEFI boot FreeBSD UNIX v14.3 with GRUB v2 either specifying everything or chainloading?  Lately when I chainload, I see graphical FreeBSD boot-loader but then after pressing <ENTER|RETURN> and a second or two it just always reboots
18:31:35 <darwin> it had installed okay, and I thought I was able to do this before.  I've booted the installation before