someone was reporting this build error: pastebin.com/m8jCRD93 on smartos, but there's nothing different from upstream that's obvious

though... that might be complaining about the rule below it looking closer

it looks like it's trying to hardlink to itself

jbk: the build error on commit: e5c93d6afd576eba5ed58a0f188357e3cc604b61

before that commit, it works normally

[illumos-gate] 15965 SMB server thread visibility in prstat -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15966 Let SMB oplocks have their own taskq -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15967 Let dynamic taskq support LWP threads -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15968 SMB worker taskq threads need reduced priority -- Gordon Ross <gwr⊙rc>

uh?

ops, E_WIN

[illumos-gate] 15988 nvme panic with Phison E18 M.2 drive -- Andy Fiddaman <illumos⊙fn>

I just realised both of us are called Jorge on the mail thread poor tsoome, the indented view is confusing with both of us singing it as Jorge at the end

Ohh some of the SMB stuff landen, speaking of did the nfs stuff also land or is that still pending I lost track of it

it is pending atm

getting closer

min vs max, a classic

everyone can make silly mistakes

god knows how many times i've inverted a comparison :)

tsoome: cool!

I produced the same type of bug myself (in simpler code), and it was significant enough that I remember it 10 years later, and it took me more than a moment to figure out what the problem is in that snippet :-)

and obviously it worked well enough for this long :)

I imagine there weren't a lot of >= 8 core desktops for most of the userbase that might have noticed it. It's interesting that the context switchiness wasn't noticed by the HPC demographic, though

I wonder how much of it was just attributed to bad NUMA aware scheduling

I don't claim to be a proficient developer let alone kernel anything, but I think that code actually does the opposite of what he thinks it does. I think it is an optimization to make systems with 8 cores or less more responsive?

The ignorant multi-cpu approach is just to have single length time slices and scale the number of scheduling slices over the number of CPUs, this seems to reduce the slice length in proportion for 8 cpus or less, which I would think would make many things running more responsive to a human

well the time slicing is always there to enable the preemption, but I think he's saying that processes/lwps are being preempted well before the CPU has been oversubscribed

whether or not that's punitive probably very much depends on workload. Presumably a good scheduler might return from the preemption with very little in the way of a context switch penalty, particularly when lazy FPU is in use

so the most pessimized workload might make this behavior noticeable, but I can see how it went unnoticed in practice for so long

notable this guy seems to be in HFT, which cares about high throughput and low latency for their given workload. That is very different from perceptive latency for things like keyboard and mouse input

That's a very keen observation

and a workload where that would probably show up

Does anyone have any of the Intel CPU models mentioned here?

I don't, but need to test illumos#16058 ( fenix )

BUG 16058: Update Intel microcode to 20231114 (New)

↳ illumos.org/issues/16058 | code.illumos.org/c/illumos-gate/+/3135

[illumos-gate] 16057 make install fails in usr/src/cmd/cmd-crypto/decrypt -- Andy Fiddaman <illumos⊙fn>

danmcd: is this the microcode patch for lock.cmpxchg8b.com/reptar.html ?

Yes.

that's a frightening CPU bug.

Yes... yes it is.

hopefully vendors take the methodology there, and start applying to their testing

Special thanks to @pjustice on #smartos for giving me a test with Ice Lake Server.

[illumos-gate] 16058 Update Intel microcode to 20231114 -- Dan McDonald <danmcd⊙mi>

[illumos-gate] 14525 Would like kmdb module for vmm -- Andy Fiddaman <illumos⊙fn>