Hi, Keir, Seems current event priority is simple by earlier-alloc-higher-priority style, because event ports are allocated incrementally from 1 and event dispatcher uses bit search instruction to walk pending events sequentially. Is there any plan (or benefit) to add more flexible priority policy, since by current way the priority is decided completely by compilation sequence of different drivers? 2nd question is, why is there check/fix upon nested events only for critical regions at end of hypervisor_callback? Though it''s possible to see nested events occurring at that small slice, seems the possibility to overflow stack at that place is similar to the normal nested cases where if some irq handler enables interrupt itself. If we really want to prevent stack overflow, is it possible to add similar logic in CONFIG_DEBUG_STACKOVERFLOW to entry point of callback, and thus make this check common for all nested cases? Seems current logic being there for a long time, and so sorry if I missed important hints here. :-) Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Tian,Kevin >Sent: 2006年4月10日 22:31 > >Hi, Keir, > Seems current event priority is simple by >earlier-alloc-higher-priority style, because event ports are allocated >incrementally from 1 and event dispatcher uses bit search instruction >to walk pending events sequentially. Is there any plan (or benefit) to >add more flexible priority policy, since by current way the priority is >decided completely by compilation sequence of different drivers?Sorry, I should say driver init sequence here. :-) Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Apr 2006, at 15:51, Tian, Kevin wrote:>> Seems current event priority is simple by >> earlier-alloc-higher-priority style, because event ports are allocated >> incrementally from 1 and event dispatcher uses bit search instruction >> to walk pending events sequentially. Is there any plan (or benefit) to >> add more flexible priority policy, since by current way the priority >> is >> decided completely by compilation sequence of different drivers? > > Sorry, I should say driver init sequence here. :-)If hardirq ''scheduling'' is demonstrated to be an issue then we can certainly work on this. There are various possible solutions -- the easiest being to simply round-robin scan the event_pending array. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2006年4月10日 23:25 >On 10 Apr 2006, at 15:51, Tian, Kevin wrote: > >>> Seems current event priority is simple by >>> earlier-alloc-higher-priority style, because event ports are allocated >>> incrementally from 1 and event dispatcher uses bit search instruction >>> to walk pending events sequentially. Is there any plan (or benefit) to >>> add more flexible priority policy, since by current way the priority >>> is >>> decided completely by compilation sequence of different drivers? >> >> Sorry, I should say driver init sequence here. :-) > >If hardirq ''scheduling'' is demonstrated to be an issue then we can >certainly work on this. There are various possible solutions -- the >easiest being to simply round-robin scan the event_pending array. > > -- KeirOK, seems currently no reports to say it as an issue in the community, and question is just from my curiosity about possible ideas. Anyway, event layer provides flexibility and we can always tune it when really required, like your suggestion. Or even we can provide guest ability to reserve fixed port range for some higher priority events, like timer virq though currently it''s already the highest one due to init sequence. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel