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.


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

(It'd require some work, but it likely should be done in some form as
part of overall RSS framework hacking.)

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

Reply via email to