From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44A39C3C.1080508@domain.hid> Date: Thu, 29 Jun 2006 11:24:12 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-core] Prio-inversion on cleanup? References: <44A1608B.3090605@domain.hid> <44A295ED.2080306@domain.hid> In-Reply-To: <44A295ED.2080306@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig685866475361B74CD6B8CF8A" Sender: jan.kiszka@domain.hid List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai-core This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig685866475361B74CD6B8CF8A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > ... > The pthread is blocked on the irqbench device ioctl. On hitting ^C, > close() is invoked from the main thread for that device. The pthread is= > woken up and obviously relaxed on some linux syscall (after being > interrupted twice by the periodic timer event of a "latency -p 300 -P > 50" instance). This passes the control over to the main thread while > keeping the pthread prio of 99. And this prio seems to survive for the > following 11 ms (full trace available on request). >=20 > Any ideas what's going on? >=20 Ok, I think I finally understood the issue. It seems to lie deep in the POSIX user-space lib, specifically its use of standard pthread services. Let me first clarify my scenario: A high-prio pthread of known and (theoretically) bounded workload shall be started and stopped while a low-prio thread is already running. The low-prio thread shall only be impacted by the real workload of the high-prio one, not by its creation/destruction - at least not significantly. To achieve this with the POSIX skin (actually this applies to preempt-rt in theory as well), I have to create the thread under SCHED_OTHER, raise its priority right before entering the workload, and lower it again before leaving the thread. But, unfortunately, __wrap_pthread_setschedparam() depends on some real_pthread functions to be called. One of them is __real_pthread_setschedparam, and this one issues a linux syscall for obvious reasons. When lowering the thread to SCHED_OTHER, this syscall is still issued under the original priority. And here we get bitten by the prio-inheritance feature of the nucleus which, in my case, lets significant parts of standard Linux execute under high priority, delaying my other real-time threads. Now I wonder how to resolve this, how to make pthread_setschedparam (a rather central RT-service) really real-time safe? I would say we need something like a lazy schedparam propagation to Linux which only takes place when the thread enters secondary mode intentionally or no other RT thread is ready. But I do not have a design for this at hand. Nasty. [My preferred way for every setup !=3D CONFIG_PREEMPT_RT + CONFIG_XENOMAI= would still be to switch this prio-inheritance off for the root thread. But this was nack'ed by Philippe several times before... ;)] Side note: the native skin does not seem to suffer from this effect as it only tracks the current prio at Xenomai level. Jan PS: Gilles, what about marking those services of the POSIX in the doc that may issue a linux syscall (and under which conditions)? --------------enig685866475361B74CD6B8CF8A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFEo5w8niDOoMHTA+kRAkl7AJkBBKjmb0xlWhv54EziHzB+YcptQACfY7Kz pqj3tIyPda4zUp+mWKnq8nk= =GU1w -----END PGP SIGNATURE----- --------------enig685866475361B74CD6B8CF8A--