On 9 May 2014 12:50, Peter Grehan <gre...@freebsd.org> wrote: >> How about i instead do the comprimise: >> >> * i'll pin all other swi's >> * default swi isn't pinned by default, but one can flip on a sysctl at >> boot time to pin it >> >> How's that sound? > > > And also please a sysctl that disables any swi pinning. > > It is sometimes useful to change the default cpuset, for instance to > allocate a subset of CPUs to some particular applications and not FreeBSD. > Having kernel threads pinned prevents this from happening since they are in > the default set. > > (Note that some network drivers are also culprits here, though disabling > MSI-x in them is a workaround).
Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff Which workloads are you thinking about? Maybe we could introduce some higher level description of which CPU(s) at boot time to do "freebsd stuff" on, and then don't start things like pcpu swi's and NIC threads on those CPUs. Can you think of situations where we'd want to have per-cpu swi's even _running_ for CPUs that you want to dedicate to other things? There's nothing stopping you from scheduling a callout on a different target CPU. (It'd require some work, but it likely should be done in some form as part of overall RSS framework hacking.) -a _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
