00:11:07 nomad Same for me; mail from Unix to S/370 machines in the same room in Germany went through NYC. Here's part of my signature from ~1988: 00:11:10 UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany) 00:11:10 ARPAnet: VBRANDT%DBNUAMA1.BITNET⊙CCE 00:27:02 CUNYVM. There's a name I have not heard in a long time.... 00:27:42 I loved when IBM mainframes would truncate lines longer than 80 characters in email messages because they were record oriented. 11:20:29 um, why I'm getting duplicate request from pushing to gerrit.... 12:09:24 So.... intrd... does disabling it on a 1 vCPU VM have any downsides? 12:09:51 I don't think I've ever seen it do something (it's supose to send stuff to syslog if it does) on a multi vCPU VM/hw either. 12:14:00 I have never seen it do anything 12:14:32 and I know of at least two rewrites in C that were started - it would be nice to get one of those integrated 12:14:40 (I think testing was one of the stumbling blocks) 12:15:06 https://hg.openindiana.org/projects/illumos/intrd/ is one of them, I think jbk did the other (apologies if my memory is wrong there) 12:31:53 and if I remember right, it tries to balance across logical CPUs, so on modern systems I'd be surprised if it does anything but take up CPU time. 12:55:27 yeah, i have a C one that i haven't finished 12:55:37 and yeah, I've never seen intrd actually do anything either :) 13:13:36 It looks like it should - I hacked it to move all interrupts to a particular CPU, which appears to have worked. It is not moving anything back because it says the interrupt load is not high enough to worry 13:15:42 but sjorge I would definitely just disable it on a single vCPU VM 13:45:43 I got it to do something! 13:45:59 i don't doubt it has the ability to move things around, i've just never encountered a system where things are so lopsided that it does :) 13:46:02 oh 13:46:05 how? :) 13:46:21 I moved all of the interrupts to a single CPU, with the same perl Intrs interface it uses. 13:46:32 then generated a lot of interrupt load with fio and sysbench 13:46:36 ahh 13:47:16 It took me from https://paste.ec/paste/c01wCx9l#npEpDibsY6Fpqn961Ab6ozArzcDKAqjBTmjUHUSpGn8 13:47:31 to https://paste.ec/paste/v09OQ-i1#YGYirTAM3YEDY86a2RcH6tei5-/Tjd9B33+7YAKpAyA 13:48:40 not anywhere near as distributed as they are on boot of course (128 threads) 13:49:05 It moved things around and all I got was this stupid '[ID 702911 daemon.notice] Interrupt assignments optimized' 14:08:03 So it shuffled the NVME's to different cpu's but then called it good enough? 14:14:37 Seems so. With high core counts these days, I doubt it often has much to do. 14:31:07 I'm going to disable it on my HW at home too 14:31:18 See if anything unexpected happens 21:31:07 sommerfeld: do you remember what 'etags -t' (the default in xref) actually does? 21:31:20 (it doesn't exist anymore) 21:37:02 sorry, I'm not finding the -t (still dealing with the aftermath of an epic battle between my laser printer and an AFCI circuit breaker) 21:40:52 xref.mk sets ETFLAGS= -t 21:41:03 which I can't find in either gnu or xemacs etags 21:41:24 I suspect it might be to ask for typedefs, and I think that happens by default now? 21:41:26 we'll see 22:02:52 I found an ancient etags binary which accepted -t (from emacs version 21); doesn't document it as an option. 22:17:02 it does appear to be typedef-related. 22:30:01 ah, I now know why it worked for me. bldenv still puts /opt/SUNWspro/bin in $PATH ... 22:40:16 it specifies etags is specifically from there, too. 22:40:24 that's what I was fixing when I discovered about -t :) 23:08:12 sommerfeld: Can you remind me where you had the topo fprintflike bug again? I'm getting bit by everyone getting the size of the topo_instance_t wrong in topo_mod_dprintfs, so I'm feeling incentivized to fix all this. 23:37:52 one sec, that workspace has been back-burnered 23:38:44 usr/src/lib/fm/topo/libtopo/common/topo_digraph_xml.c 23:40:29 https://www.illumos.org/issues/15435 23:40:30 → BUG 15435: libtopo fails to build when fprintf is marked __PRINTFLIKE() (New) 23:43:27 rmustacc: two issues: missing comma led to compile-time string concat with all subsequent arguments being off by one, and the generated XML looks wrong (tagging a double as a uint64)