On Mon, Dec 25, 2000 at 11:13:11AM -0500, jamal wrote:
>
>
> 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.
The SPL stuff predates BSD by a long way. It was in 6th edition and probably
earlier than that. I wouldn't say the we "lower" the priority, but we do have
a hierarchy such that there are lower priority interrupt routines that can
be pre-empted by higher priority ones. However, it is not necessary to go to
these lengths to take advantage of the APIC priority stuff. It is nowehere
written in stone that there have to be eight interrupt priority levels. If we
were to choose two, for instance, that collapses down to map simply to what
Linux uses today, except that by replacing cli/sti we would achieve sane
interrupt distribution.
> 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.
>
I suspect we're closer together than you might think. The SPL hierarchy thing
may turn out to be less valuable than the complexity justifies. The first
thing to do is to change the APIC programming.
> 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.
>
I'd need to think about that. I'm not sure how practical that is on an x86.
Of course, the way it's done in ptx would guarantee that provided that at
least one cpu in the system wasn't already busy in an interrupt routine.
> > 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.
>
Will work on it....
Watch this space :-)
Regards,
Tim
--
Tim Wright - timw@xxxxxxxxx or timw@xxxxxxxxxxx or twright@xxxxxxxxxx
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
|