Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff
Thanks, that'll work.
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.
A classic case is partitioning cores into control and data plane groups. I'm sure there are lots more. What's nice about cpuset is that the choice and change can be dynamic, so long as there aren't pinned threads in the default set.
An option to restrict FreeBSD pCPU threads to a subset could be useful.
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.
At least for the uses I know, it's complete isolation from other processing, kernel threads included. The 'freebsd stuff' info you mentioned should be sufficient.
later, Peter. _______________________________________________ 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"
