> On Feb 8, 2020, at 12:45 PM, Andrew Doran <a...@netbsd.org> wrote:
>
> Bit concerning that we're growing a ton of kthreads in the network stack (my
> test system now has something like 700 kthreads total) but I'm less worried
> about that and moreso that a lot of these seem to be in the kernel RT range
> and will therefore cause kernel preemptions when triggered.
>
> For something like a link state change that's no biggie but I'm not fond of
> the idea of bulk wire & protcol processing needing mi_switch() + kpreempt().
> Way back when we made a concious decision not copy the design pattern our
> sister project went with on this front. Maybe it is the right way to go now
> but I think that should also be a concious design decision.
Roger that. I agree with you -- I would prefer "regular" stuff to continue
using softints. For some other stuff, though, we've made the policy decision
that softints can't block for anything other than an adaptive mutex, which is
fine... this particular case sends a message to the routing socket, which
requires gathering interface statistics, which blocks on something other than
an adaptive mutex.
I'm not a fan of the workqueue interface, and I have something better sitting
unfinished in my Bucket Of Stuff I'm Working On ... a generalized "task"
interface originally written-but-not-finished by Taylor that uses either thread
pools or softints to do the work... so at least the threads won't linger around
in the "mostly idle" case.
-- thorpej
