Re: ithread priority question...

From: Julian Elischer <julian_at_elischer.org>
Date: Tue, 22 Jun 2004 15:27:01 -0700 (PDT)
On Tue, 22 Jun 2004, John Baldwin wrote:

> On Monday 21 June 2004 03:48 am, Julian Elischer wrote:
> > On Mon, 21 Jun 2004, Bruce Evans wrote:
> > > On Sun, 20 Jun 2004, Julian Elischer wrote:
> > > > In swi_add, the priority is multiplied by PPQ.
> > > > This is a layering violation really because PPQ should only be known
> > > > within the scheduler.... but..... "Why multiply by PPQ inthe first
> > > > place?"  we are not using the system run queues for interrupt threads.
> > > >
> > > > (PPQ = Priorities Per Queue).
> > > >
> > > > Without this you can remove runq.h from proc.h  and include it only in
> > > > the scheduler related files.
> > >
> > > I agree that this makes no sense.  Apart from the layering violation,
> > > It seems to just waste priority space.  The wastage is not just cosmetic
> > > since someone increased the number of SWIs although there was no room
> > > for expansion.
> > >
> > >
> > > Hardware ithread priorities are also separated by 4.  The magic number 4
> > > is encoded in their definitions in priority.h.  It's not clear if the 4
> > > is PPQ or just room for expansion without changing the ABI.  Preserving
> > > this ABI doesn't seem very important.
> >
> > seems pointless to me..
> > It looks to me that at on stage someone was considerring using the
> > standard run-queue code to make interrupt threads runnable.
> > They wanted each interrupt thread to eb on a differen queue and to use
> > the ffs() code to find the next one to run.
> 
> That was the intention.  One question though, if the ithreads aren't on the 
> system run queues then which run queues are they on?

aren't they run from the interupt?


> 
> -- 
> John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
> 
Received on Tue Jun 22 2004 - 20:27:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC