Re: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Lundi 13 Mars 2006 14:11, Tian, Kevin a écrit :
> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>
> >Sent: 2006年3月13日 17:32
> >
> >Le Jeudi 09 Mars 2006 21:02, Tian, Kevin a écrit :
> >> Anyway, good discussion by far though still some way to go for
> >> consensus. :-)
> >>
> >> Maybe we want to look at this from another way - fairness.
> >
> >[...]
> >
> >> Regarding current model, there seems to be an issue about fairness
> >> between physical interrupts and "xen events". Taking current 0xE9 for
> >> example, it's lower than timer but higher than all external device
> >> interrupts. This means "xen events" will always preempt device
> >> interrupts in this case, which is unfair and not what we want.
> >
> >To my understanding, this is also true for x86.
> >With event channel, real physical IRQs use events 0-255, while Xen events
> >use
> >events 256-511.
> >
> >So what is the difference ?
>
> Difference is obvious, because 0-255 or 256-511 is not the first level of
> priority decision. The base line is always evtchn_pending, with lower bit
> for higher priority by far. Phys_irq may have event port higher than the
> one owned by a dyn_irq, thus the priority of the former is instead lower
> than the latter. Phys_irq in 0-255 and dyn_irq in 256-511 are just one
> compatible way to the end user, with former indicating normal interrupt
> while the latter for new type of events.
>
> Yes, currently the priority of event channel is a simple way as
> earlier-come-higher-priority, which is decided by the init sequence of
> different drivers. But once event layer is added under traditional
> interrupt, you can choose more complex/accurate priority policy on demand.
> That's it!
Ok. Understood.

Tristan.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel