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:

UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany)

ARPAnet: VBRANDT%DBNUAMA1.BITNET⊙CCE

CUNYVM. There's a name I have not heard in a long time....

I loved when IBM mainframes would truncate lines longer than 80 characters in email messages because they were record oriented.

um, why I'm getting duplicate request from pushing to gerrit....

So.... intrd... does disabling it on a 1 vCPU VM have any downsides?

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.

I have never seen it do anything

and I know of at least two rewrites in C that were started - it would be nice to get one of those integrated

(I think testing was one of the stumbling blocks)

hg.openindiana.org/projects/illumos/intrd is one of them, I think jbk did the other (apologies if my memory is wrong there)

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.

yeah, i have a C one that i haven't finished

and yeah, I've never seen intrd actually do anything either :)

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

but sjorge I would definitely just disable it on a single vCPU VM

I got it to do something!

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 :)

oh

how? :)

I moved all of the interrupts to a single CPU, with the same perl Intrs interface it uses.

then generated a lot of interrupt load with fio and sysbench

ahh

It took me from paste.ec/paste/c01wCx9l#npEpDibsY6Fpqn961Ab6ozArzcDKAqjBTmjUHUSpGn8

to paste.ec/paste/v09OQ-i1#YGYirTAM3YEDY86a2RcH6tei5-/Tjd9B33+7YAKpAyA

not anywhere near as distributed as they are on boot of course (128 threads)

It moved things around and all I got was this stupid '[ID 702911 daemon.notice] Interrupt assignments optimized'

So it shuffled the NVME's to different cpu's but then called it good enough?

Seems so. With high core counts these days, I doubt it often has much to do.

I'm going to disable it on my HW at home too

See if anything unexpected happens

sommerfeld: do you remember what 'etags -t' (the default in xref) actually does?

(it doesn't exist anymore)

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)

xref.mk sets ETFLAGS= -t

which I can't find in either gnu or xemacs etags

I suspect it might be to ask for typedefs, and I think that happens by default now?

we'll see

I found an ancient etags binary which accepted -t (from emacs version 21); doesn't document it as an option.

it does appear to be typedef-related.

ah, I now know why it worked for me. bldenv still puts /opt/SUNWspro/bin in $PATH ...

it specifies etags is specifically from there, too.

that's what I was fixing when I discovered about -t :)

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.

one sec, that workspace has been back-burnered

usr/src/lib/fm/topo/libtopo/common/topo_digraph_xml.c

→ BUG 15435: libtopo fails to build when fprintf is marked __PRINTFLIKE() (New)

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)