[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-ia64-devel] Event channel vs current scheme speed [wasvIOSAPIC and IRQs delivery]
> I agree the current model has implicit priorities. > > But I am a little bit skeptical how the priority argument. As far as > I understand, in Xen or in Linux first asked is first priority. Yes, here we see 3 concerns about priority: 1: When multiple IRQs arrive at same time, higher priority one get earlier serviced in native. In xen event channel, higher priority IRQ can have higher priority event channel. So they are basically same. 2: A lower IRQ arrives first, then followed by an high priority IRQ. In this case, the situation is relative complicate. If the duration is big enough, yes the first asked is serviced. If the duration is small, then later one may preempt the first one. In virtual machine environment, the time is virtualized. So no matter which one is service first has no correctness issue (you can think the virtual duration maybe big maybe large). 3: A higher IRQ arrives first, then followed by an lower priority IRQ. In this case, higher IRQ must be serviced earlier than lower one. Xen event channel search the highest priority IRQ and do service. At service time, the callbreak is masked but the event can still be set. So a lower IRQ can't interrupt higher one. Semantics are guaranteed. > >> All in all, above long context is just one factor that I view to >> choose the proper mechanism. :-) > If you are that worried about priorities, we way find solution in the > current scheme. I'd just like to understand why priorities are that > important. These are all corner cases that we must consider as product, but at early development we can take shortcut like using pseudo IRQ for event channel here to let the whole project go ahead. And this is what we talked at xensummit, people (Dan, Ian, Keir, Jun) all have no object for potential issue concerns (for example mask/unmask support and priority issue) and agree to take next. PPC guy also uses pseudo physical IRQ for event channel as I remembered. Their community is much smaller than us now and their development is also lagger than IA64. This is why we need to clean up now as callback based event channel approach has already been in production stage. Making a new mechanism has high risk. BTW, even with this strong event channel mechanism in Xen, we sometime saw bugs in xen-devl such as a deadlock in a VMX SMP system like Xin rootcaused before new year. But anyway it is very few now. Eddie _______________________________________________ Xen-ia64-devel mailing list Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-ia64-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |