On Mon, 25 Dec 2000, Tim Wright wrote:
> On Sun, Dec 24, 2000 at 09:59:34PM -0500, jamal wrote:
> >
> >
> > So it seems that the process is capable of setting a high enough priority
> > such that an (hardware) interupt wont run on a specific CPU?
>
> No, all user processes are pre-emptible. DYNIX/ptx doesn't support the notion
> of RT processes. The range of user priorities is crunched down into 4 bits.
> Locking out of interrupts below a given SPL is achieved by programming a
> different register IIRC, although it is also mirrored in the TPR (task
> priority register), and SPL1 is "higher" priority than any user process.
I see. I think i understand what Andi was saying earlier. You are
generally proposing some bsdish SPL* scheme which also applies to
hardware interupts(?). i.e it looks to me with your idea, you might
lower the priority of a hardware interupt. Seems like our goals might
intersect somewhere b ut not as simple as i thought earlier.
In essence, i am looking for some way to define sophisticated interupt
scheduling via a policy.
Simple example of what i'd like to experiment with:
A policy such as : "IRQ3 and IRQ5 are mutually exclusive". The mechanism
should then ensure that at any point in time if IRQ3 and IRQ5 get set
they get routed to two different CPUs.
> That is what we do. I don't know if we have a paper, but it sounds like we
> should. It's actually quite likely that I can publish the relevant code
> with little difficulty.
>
Code would help.
cheers,
jamal
|