On Thursday, May 08, 2014 11:43:39 pm Adrian Chadd wrote:
> I'd like to revisit this now.
> I'd like to commit this stuff as-is and then take some time to revisit
> the catch-all softclock from cpu0 swi. It's more complicated than it
> needs to be as it just assumes timeout_cpu == cpuid of cpu 0. So
> there's no easy way to slide in a new catch-all softclock.
> Once that's done I'd like to then experiment with turning on the pcpu
> tcp timer stuff and gluing that into the RSS CPU ID / netisr ID stuff.
To be clear, are you going to commit the change to bind all but CPU 0
to their CPU but let the "default" swi float for now? I think that is
fine to commit, but I wouldn't want to bind the "default" swi for now.
> On 20 February 2014 13:48, Adrian Chadd <adr...@freebsd.org> wrote:
> > On 20 February 2014 11:17, John Baldwin <j...@freebsd.org> wrote:
> >> (A further variant of this would be to divorce cpu0's swi from the
> >> catch-all softclock and let the catch-all softclock float, but bind
> >> all the per-cpu swis)
> > I like this idea. If something (eg per-CPU TCP timers, if it's turned
> > on) makes a very specific decision about the CPU then it should be
> > fixed. Otherwise a lot of the underlying assumptions for things like
> > RSS just aren't guaranteed to hold.
> > It could also perhaps extend to some abstract pool of CPUs later, if
> > we wanted to do things like one flowing swi per socket or whatnot when
> > we start booting on 1024 core boxes...
> > -a
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"