FYI for next time there is a USB group; feel free to add it or yourself to it if you are interested in USB.

In D27871#1101805, @des wrote:

I realize this is quite old, but I'd like to discuss the possibility of reverting 5844bd058aed, as it appears to have a significant performance impact which was never discussed at the time, while the benefit of the change appears to be purely hypothetical. I have no reason to doubt that pgrp_calc_jobc() is correct, but my own attempts to investigate possible errors in tracking pg_jobc did not uncover anything except an unrelated race condition in ppoll() and pselect() (cf. D47738 and D47741). I know of historical instances, e.g. D26116, but see no evidence of any unresolved issues at the time. Meanwhile, the cost of pgrp_calc_jobc() is quite high, especially in a debugging kernel where the process tree lock is being asserted at least four times per iteration of the inner loop, and it is being incurred even when no change occurs, e.g. on every ps or procstat -a or refresh of top.

rebase

In D46296#1101873, @editor_callfortesting.org wrote:

Could someone provide some simple scripts for bringing up and testing a share?

@bz Was that question directed to @emaste regarding the documentation change D48262 as opposed to this code change D47512?

Define and use VM_RADIX_FOREACH macros. Initialize a couple of iterators before acquiring read locks.

Could someone provide some simple scripts for bringing up and testing a share?

Reverse course, just move sc_cpuids out from underneath SMP and let it allocatee
a single-entry sc_cpuids. The overhead of still doing intr_irq_next_cpu() is
minimal since it's simply a PCPU_GET(cpuid) on !SMP kernels.