From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <479BCE17.600@domain.hid> Date: Sun, 27 Jan 2008 01:19:35 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <2ff1a98a0801020231k19be7d89k1a6f04b7d497cc34@domain.hid> <18315.63245.160672.547658@domain.hid> <18326.21480.397736.413726@domain.hid> <47977DE1.8060207@domain.hid> <2ff1a98a0801230953m2a67e614s6c921b3b6ec77c3c@domain.hid> <479788A5.80407@domain.hid> <2ff1a98a0801240218y1f09ae38w93e244a47218900@domain.hid> <479B7938.2000206@domain.hid> <18331.32587.725949.407764@domain.hid> In-Reply-To: <18331.32587.725949.407764@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: Philippe Gerum Subject: Re: [Xenomai-core] High latencies on ARM. Reply-To: rpm@xenomai.org List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai-core Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > Gilles Chanteperdrix wrote: > > > On Jan 23, 2008 7:34 PM, Philippe Gerum wrote: > > >> Gilles Chanteperdrix wrote: > > >>> On Jan 23, 2008 6:48 PM, Philippe Gerum wrote: > > >>>> Gilles Chanteperdrix wrote: > > >>>>> Gilles Chanteperdrix wrote: > > >>>>> > Please find attached a patch implementing these ideas. This adds some > > >>>>> > clutter, which I would be happy to reduce. Better ideas are welcome. > > >>>>> > > > >>>>> > > >>>>> Ok. New version of the patch, this time split in two parts, should > > >>>>> hopefully make it more readable. > > >>>>> > > >>>> Ack. I'd suggest the following: > > >>>> > > >>>> - let's have a rate limiter when walking the zombie queue in > > >>>> __xnpod_finalize_zombies. We hold the superlock here, and what the patch > > >>>> also introduces is the potential for flushing more than a single TCB at > > >>>> a time, which might not always be a cheap operation, depending on which > > >>>> cra^H^Hode runs on behalf of the deletion hooks for instance. We may > > >>>> take for granted that no sane code would continuously create more > > >>>> threads than we would be able to finalize in a given time frame anyway. > > >>> The maximum number of zombies in the queue is > > >>> 1 + XNARCH_WANT_UNLOCKED_CTXSW, since a zombie is added to the queue > > >>> only if a deleted thread is xnpod_current_thread(), or if the XNLOCKSW > > >>> bit is armed. > > >> Ack. rate_limit = 1? I'm really reluctant to increase the WCET here, > > >> thread deletion isn't cheap already. > > > > > > I am not sure that holding the nklock while we run the thread deletion > > > hooks is really needed. > > > > > > > Deletion hooks may currently rely on the following assumptions when running: > > > > - rescheduling is locked > > - nklock is held, interrupts are off > > - they run on behalf of the deletor context > > > > The self-delete refactoring currently kills #3 because we now run the > > hooks after the context switch, and would also kill #2 if we did not > > hold the nklock (btw, enabling the nucleus debug while running with this > > patch should raise an abort, from xnshadow_unmap, due to the second > > assertion). > > Forget about this; shadows are always exited in secondary mode, so that's fine, i.e. xnpod_current_thread() != deleted thread, hence we should always run the deletion hooks immediately on behalf of the caller. > > It should be possible to get rid of #3 for xnshadow_unmap (serious > > testing needed here), but we would have to grab the nklock from this > > routine anyway. > > Since the unmapped task is no longer running on the current CPU, is no > there any chance that it is run on another CPU by the time we get to > xnshadow_unmap ? > The unmapped task is running actually, and do_exit() may reschedule quite late until kernel preemption is eventually disabled, which happens long after the I-pipe notifier is fired. We would need the nklock to protect the RPI management too. -- Philippe.