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.


>> 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.


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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to