common base64 sounds grand

(there's one there', but under iscsi/ for some reason)

rmustacc: are there any plans to document MAC_GROUP_TYPE_DYNAMIC (and is there any good place to figure out details on it aside from looking at nxge?)

it _seems_ like maybe it's something that ice could support in the future (not going to attempt it initially) unlike i40e

I had no plans to document or continue to try to use it.

While some dynamicism in rings is probably warranted, not clear to me that way is what we want or not and it's a lot of complexity everywhere.

[illumos-gate] 13918 Want kernel test facility (IPD 20) -- Ryan Zezeski <ryan⊙zc>

tsoome: Hi, is it possible to limit number of CPUS via bootloader menu, i.e. during boot process?

you can set ncpus value, but would need to check the exact name for property

why do you need that?

it may be plat-max-ncpus

tsoome: I need to check how NUMA and two-processors affects on system performance. I would like to disable 2nd processor.

I see.

Maybe easier to use psradm?

Because setting ncpus doesn't guarantee CPU enumeration order.

harder to judge how perf falls through into the kernel then

I don't think we stop taskq's and stuff from fanning back out?

(like, especially, for zfs i/o)

For some stuff yeah. It's not properly wired into cpu online/offline.

that might be the noise when i was trying to benchmark the impact of adding frame pointer to the str* assembly routines

i couldn't get consistent figures to assess the impact

Did you put yourself in rt?

rt, interrupts disabled, bound to 1 core, other thread in the core turned off

(interrupts disabled on that core)

via pbind / psradm / priocntl as I recall (it's been a bit)

i also maybe wonder if cacheing might have been getting in there as well.. though not sure offhand how to control for that

i know (this was a while ago) jperkin did do a pkgsrc build w/ the changes and didn't notice any change in the runtime, so there was that... probably a decent check (in addition to the tests i wrote) that nothing broke

I would assume the impact of real stack frames for (many) str* mem* to be really complicated to measure without a very carefully selected and tuned workload

but not sure how sufficient of a data point in terms of not being noticably worse in terms of perf

I'd imagine you'd be looking at blasting it with iperf and other things that might convince it to not zero-copy

presuming you hit bcopy/memcpy/memmove

basically it seems like the common case is going to be such a tiny amount slower that you'd have to engineer a realistic load that got in there as much as possible, and did as little else as possible

i suspect a lot of them have some amount of fixed overhead and then overhead based on the data size, which would penalize small strings more (relatively speaking)

this was just libc

I expect to be honest that it would be much more complex than that; I feel like there is some level of register-like magic available for some limited number of stack slots on modern x86

which would depend a lot on where the speculation stuff was, how deep your stacks are, etc

it would be nice though to have it if it's not going to hurt us...

though might also be nice to utilize some of the newer instructions for some of those as well... though that's likely triciker since it's not always obvious which things would be 'best' to use

(e.g. avx512 I guess is fine on newer CPUs, but can be slower in older cpus in some conditions, etc. i imagine other instructions would probably be similarly annoying to know when they'd be better to use)

Yes I think empiricism is unfortunately all there is, in many cases

perhaps you could watch for significant differences in cpu perf counters

but that's only going to tell you about that cpu model/family/whatever

[illumos-gate] 16724 vfs tests are not i386 only -- Robert Mustacchi <rm⊙fo>

I guess what everyone is saying is "yeah, that's a real bugger that is"

I'm working on illumos.org/issues/16719 to add git clone support to nightly. Does anyone know if anyone is still using mercurial to manage their local illumos-gate trees?

→ FEATURE 16719: nightly should be able to create and update build trees from git (In Progress) | code.illumos.org/c/illumos-gate/+/3642

I don't think so, but I'm not sure

I'm not even sure the hg-git bridging we used would still line things up properly

Right now, nightly assumes ssh:// workspace URLs are mercurial. I could spend time trying to figure out a way to probe remotely, or I could just flip it to git.

I would flip it and not worry at all

I really don't think anyone in illumos-land uses hg anymore for illumos or its children.

yeah, the last person I knew of was igor, and I'm pretty sure that stopped because the bridge became incompatible with itself like, 4 times since we used it

for what it's worth, I don't think anyone ever really used bringover support here

I've thought about removing it, and the copy-up of build product etc.

but I like this idea more

[illumos-gate] 16725 mdb: disk_label mbr command should show BIOS parameter block -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16699 viona should expose kstats -- Patrick Mooney <pmooney⊙pc>