[quagga-dev 3358] Re: thread_fetch ready logic
Andrew J. Schorr
aschorr at telemetry-investments.com
Wed Apr 27 19:26:24 BST 2005
On Wed, Apr 27, 2005 at 07:16:39PM +0100, Paul Jakma wrote:
> Indeed. But lower priority within a given run of the scheduler.
I don't follow this logic. How do you define a "given run"?
A single call to thread_fetch?
> A thread on some future run of the scheduler does not have priority
> over it. If it did, you could never ever guarantee that a background
> thread would run. (indeed, at present, only events are guaranteed to
But I think you are blurring the distinction between a background timer
and a foreground timer. Is there really much difference between
the two if treated as you propose?
> Right, but not till we've already put any pending IO or foreground
> timer onto the ready list /ahead/ of it.
True for a single run. But I'm not sure I follow your subtle logic here.
In my view, a background timer thread should not run unless there's no
other work to do. Your proposal does not have that behavior.
> See above, should the background timer /ever/ run? (And
> pre-workqueue, same for IO versus timer). It's not important it runs
> right now, but its still work - it should still be done at /some/
I'm not clear on this. If the system is swamped, the idea is that a
background thread can run later. So no, it would not run until the
process has some spare cycles. That makes sense to me. Otherwise,
if processing in a timely fashion is required, it should be a foreground
timer, not a background timer.
Bottom line: to really solve this correctly requires explicit thread
priorities. Otherwise, we are basically just assuming that there's
more than enough CPU to go around. In practice, that's basically
OK and probably not worth changing. But I still think background
threads should run strictly at lowest priority...
More information about the Quagga-dev