From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B28EF6D.5020405@domain.hid> Date: Wed, 16 Dec 2009 15:32:13 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4B240D0B.50603@domain.hid> <1260723757.2216.2.camel@domain.hid> <4B252909.9090304@domain.hid> <1260727502.2216.19.camel@domain.hid> <4B253028.10607@domain.hid> <1260962769.2216.203.camel@domain.hid> <4B28CA44.2080304@domain.hid> <1260973175.2216.371.camel@domain.hid> In-Reply-To: <1260973175.2216.371.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34DEA29DAA1E3DBA32EB7057" Sender: jan.kiszka@domain.hid Subject: Re: [Adeos-main] [pull request] x86: critical fix for native_safe_halt List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: adeos-main This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34DEA29DAA1E3DBA32EB7057 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 f= law in >>>>>>>> cpu_idle on x86: We failed to check the pipeline log before issu= ing the >>>>>>>> real hlt. This caused IRQ latencies or even drops for Linux, >>>>>>>> specifically on SMP. Credits go to plain QEMU whose slow SMP mod= e caused >>>>>>>> ipipe_critical_enter to deadlock frequently enough. >>>>>>>> >>>>>>>> The first patch of this series fixes this (see below), the secon= d one >>>>>>>> simply removes the two useless ipipe_suspend_domain calls. >>>>>>>> >>>>>>> What your patch does as well, is killing the ability to run low p= riority >>>>>>> domains below the root level. >>>>>> Yes, I'm killing the dream. >>>>>> >>>>>> I heavily doubt that the functions I removed in the second patch e= ver >>>>>> contributed something good to this. It's always the job of the low= est >>>>>> domain to issue hardware halt, not of some arbitrary mid-prio doma= in. >>> 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 priori= ty >>> domain to act upon when a mid priority domain is about to enter the C= PU >>> 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. >=20 > 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. >=20 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 --------------enig34DEA29DAA1E3DBA32EB7057 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkso73QACgkQitSsb3rl5xRPxwCcDVSKubd7H8LZg9LaWCKc/DyN 5NcAnjfKaco6xivTai+lWzsFdD6ByWU6 =+p/7 -----END PGP SIGNATURE----- --------------enig34DEA29DAA1E3DBA32EB7057--