00:16:12 common base64 sounds grand 00:16:34 (there's one there', but under iscsi/ for some reason) 14:44:09 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?) 14:45:19 it _seems_ like maybe it's something that ice could support in the future (not going to attempt it initially) unlike i40e 15:05:50 I had no plans to document or continue to try to use it. 15:07:00 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. 15:10:37 [illumos-gate] 13918 Want kernel test facility (IPD 20) -- Ryan Zezeski 18:07:49 tsoome: Hi, is it possible to limit number of CPUS via bootloader menu, i.e. during boot process? 18:08:31 you can set ncpus value, but would need to check the exact name for property 18:09:02 why do you need that? 18:11:15 it may be plat-max-ncpus 18:13:24 tsoome: I need to check how NUMA and two-processors affects on system performance. I would like to disable 2nd processor. 18:14:40 I see. 18:15:41 Maybe easier to use psradm? 18:16:01 Because setting ncpus doesn't guarantee CPU enumeration order. 18:21:54 harder to judge how perf falls through into the kernel then 18:22:10 I don't think we stop taskq's and stuff from fanning back out? 18:22:30 (like, especially, for zfs i/o) 18:25:11 For some stuff yeah. It's not properly wired into cpu online/offline. 18:25:16 that might be the noise when i was trying to benchmark the impact of adding frame pointer to the str* assembly routines 18:25:28 i couldn't get consistent figures to assess the impact 18:25:46 Did you put yourself in rt? 18:26:11 rt, interrupts disabled, bound to 1 core, other thread in the core turned off 18:26:31 (interrupts disabled on that core) 18:27:21 via pbind / psradm / priocntl as I recall (it's been a bit) 18:36:22 i also maybe wonder if cacheing might have been getting in there as well.. though not sure offhand how to control for that 18:37:52 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 18:38:02 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 18:38:16 but not sure how sufficient of a data point in terms of not being noticably worse in terms of perf 18:38:51 I'd imagine you'd be looking at blasting it with iperf and other things that might convince it to not zero-copy 18:39:00 presuming you hit bcopy/memcpy/memmove 18:39:52 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 18:41:09 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) 18:41:13 this was just libc 18:43:48 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 18:44:18 which would depend a lot on where the speculation stuff was, how deep your stacks are, etc 18:54:07 it would be nice though to have it if it's not going to hurt us... 18:55:49 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 18:56:48 (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) 19:03:28 Yes I think empiricism is unfortunately all there is, in many cases 19:14:57 perhaps you could watch for significant differences in cpu perf counters 19:15:10 but that's only going to tell you about that cpu model/family/whatever 19:24:57 [illumos-gate] 16724 vfs tests are not i386 only -- Robert Mustacchi 19:30:45 I guess what everyone is saying is "yeah, that's a real bugger that is" 20:08:33 I'm working on https://www.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? 20:08:34 → FEATURE 16719: nightly should be able to create and update build trees from git (In Progress) | https://code.illumos.org/c/illumos-gate/+/3642 20:10:57 I don't think so, but I'm not sure 20:11:42 I'm not even sure the hg-git bridging we used would still line things up properly 20:13:41 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. 20:14:34 I would flip it and not worry at all 20:25:15 I really don't think anyone in illumos-land uses hg anymore for illumos or its children. 20:31:49 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 20:33:00 for what it's worth, I don't think anyone ever really used bringover support here 20:33:16 I've thought about removing it, and the copy-up of build product etc. 20:33:24 but I like this idea more 20:51:12 [illumos-gate] 16725 mdb: disk_label mbr command should show BIOS parameter block -- Toomas Soome 22:45:55 [illumos-gate] 16699 viona should expose kstats -- Patrick Mooney