Philippe Gerum wrote: > On Wed, 2009-12-16 at 12:53 +0100, Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Sun, 2009-12-13 at 19:19 +0100, Jan Kiszka wrote: >>>> Philippe Gerum wrote: >>>>> On Sun, 2009-12-13 at 18:48 +0100, Jan Kiszka wrote: >>>>>> Philippe Gerum wrote: >>>>>>> On Sat, 2009-12-12 at 22:37 +0100, Jan Kiszka wrote: >>>>>>>> Recent moving of ipipe_suspend_domain finally exposed a deeper flaw in >>>>>>>> cpu_idle on x86: We failed to check the pipeline log before issuing the >>>>>>>> real hlt. This caused IRQ latencies or even drops for Linux, >>>>>>>> specifically on SMP. Credits go to plain QEMU whose slow SMP mode >>>>>>>> caused >>>>>>>> ipipe_critical_enter to deadlock frequently enough. >>>>>>>> >>>>>>>> The first patch of this series fixes this (see below), the second one >>>>>>>> simply removes the two useless ipipe_suspend_domain calls. >>>>>>>> >>>>>>> What your patch does as well, is killing the ability to run low priority >>>>>>> domains below the root level. >>>>>> Yes, I'm killing the dream. >>>>>> >>>>>> I heavily doubt that the functions I removed in the second patch ever >>>>>> contributed something good to this. It's always the job of the lowest >>>>>> domain to issue hardware halt, not of some arbitrary mid-prio domain. >>> Actually, no it's not. You may use a low-priority domain to run idle >>> level jobs outside of the linux infrastructure for that purpose (e.g. >>> RCU). A high priority domain may want to post events for a low priority >>> domain to act upon when a mid priority domain is about to enter the CPU >>> idle state. >> Even if all the related bugs were fixed: When you pass down control to >> the lower domain on cpu_idle via ipipe_suspend_domain, you won't get a >> Linux reschedule (without CONFIG_PREEMPT) until the low-prio domain >> finally returns from its event handler - likely not what "low-prio" >> suggests. > > low prio suggests nothing else than "runs whenever nothing else has to > be done higher in the pipeline". I just don't get why you seem to bind > the Linux rescheduling logic with what a low prio domain would do; by > definition, adeos-wise, both are totally non-related. >
I meant that a low prio domain is able to (indirectly) defer activities of a mig prio domain due to the way the latter passed on the control in its idle loop. Think about my scenario again: where are the preemption points of on idle, !CONFIG_PREEMPT Linux kernel? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
