Date: Thu, 5 May 2022 15:34:54 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Hans Petter Selasky <hps@selasky.org>, arch@FreeBSD.org Cc: gallatin@FreeBSD.org Subject: Re: Time sharing for interrupt threads Message-ID: <c2eae141-46dc-c531-9bf1-a1c5ff906bd8@FreeBSD.org> In-Reply-To: <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org> References: <ac532f32-97b2-59a1-2cb9-25a083cf7329@FreeBSD.org> <04f80ff1-2374-8f49-ac13-1c55570cb6c0@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c2eae141-46dc-c531-9bf1-a1c5ff906bd8>