Re: Time sharing for interrupt threads

On 5/5/22 12:11 AM, Hans Petter Selasky wrote:
> On 5/4/22 23:48, John Baldwin wrote:
>> My recent changes to the softclock threads (raising their priority) were to
>> address a livelock issue in which a constant stream of packets could starve
>> timeout events.
> 
> Sorry for short-cutting the thread, but why can't we have multiple
> worker threads with different prio's for timers? In USB we have that,
> once for Giant locked and non-Giant locked callbacks. I mean, all timer
> interrupts are executed serially and any congested mutex will make all
> succeeding timer callbacks halt on that CPU core!

We do have per-CPU threads at least.  However, this particular problem is
orthogonal I think to the notion of if we want to enable time-sharing for
ithreads in general.  Having multiple workers for callouts raises its own
interesting problems such as how you decide how to schedule callouts among
multiple threads.  I suspect that the number of callouts using Giant are
fairly inconsequential at this point so Giant vs non-Giant probably isn't
compelling.  You could perhaps add some kind of scheduler-activations
type thing where you either spawn or wakeup another thread when a callout
handler blocks on a lock.  That would be a fair bit of work though and
not really related to this proposal.

-- 
John Baldwin