On 9 May 2014 16:49, Peter Grehan <gre...@freebsd.org> wrote: >> 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.
Cool. >> 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. Cool. I'll look at committing this stuff in the next few hours. It can always easily be undone. I'll revisit the "limit pcpu threads to cpuids <x>" idea later. -a _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"