From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4F0C7A97.5070407@domain.hid> Date: Tue, 10 Jan 2012 18:51:19 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <4F0B530A.80905@domain.hid> <4F0C5524.9020501@domain.hid> <4F0C58B7.1080602@domain.hid> <4F0C5C00.3060508@domain.hid> <4F0C5C02.50308@domain.hid> <4F0C5C63.40105@domain.hid> <4F0C5E85.5080004@domain.hid> In-Reply-To: <4F0C5E85.5080004@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Issue with Auto relax and nested mutexes List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Makarand Pradhan Cc: "xenomai@xenomai.org" On 01/10/2012 04:51 PM, Makarand Pradhan wrote: > Based on my testing, it is noted that the rescnt is not released when > task1 gets a priority boost and starts running with priority 1. That's > when the rescnt is not decremented. > Ah, bad side effect of __xnsched_rt_setparam likely. Ok, I need to have a deeper look, but this would make sense. > It would imply that we may be checking the current priority while > testing if we want to invoke rt_mutex_release in kernel. Will try to > check it out. > > Rgds, > Mak. > > On 10/01/12 10:42 AM, Philippe Gerum wrote: >> On 01/10/2012 04:40 PM, Philippe Gerum wrote: >>> On 01/10/2012 04:40 PM, Makarand Pradhan wrote: >>>> Another point: >>>> >>>> "These are fast mutexes, the thread does not have to jump to kernel >>>> space >>>> unless the released mutex was actually contented." >>>> >>>> When the first task is started with prio 0, I always see that >>>> rt_mutex_release is invoked in the kernel. even when there is no >>>> contention. >>> I should have added: "unless there is no contention ... or the caller is >>> a non-rt thread". This is because we have to jump to kernel space to >>> track rescnt. >>> >> Ok, next try: "unless the mutex was contented ... or the caller is >> a non-rt thread". >> >>>> I have an instrumented kernel. The kernel trace is given below. In this >>>> trace only task1 is running at prio 0. It should be easy to follow: >>>> >>>> Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 0, switched: 0 >>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 0, switched: 0 >>>> Jan 10 10:36:59 ruggedcom kernel: lo: rescnt: 1, switched: 1 >>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 2, switched: 0 >>>> Jan 10 10:36:59 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:01 ruggedcom kernel: RML >>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:01 ruggedcom kernel: RML >>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 1, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:01 ruggedcom kernel: RML >>>> Jan 10 10:37:01 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:01 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 0, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: lo: rescnt: 1, switched: 1 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 2, switched: 0 >>>> Jan 10 10:37:01 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:03 ruggedcom kernel: RML >>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:03 ruggedcom kernel: RML >>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 1, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: __rt_mutex_release >>>> Jan 10 10:37:03 ruggedcom kernel: RML >>>> Jan 10 10:37:03 ruggedcom kernel: rt_mutex_release: lockcnt: 1 >>>> Jan 10 10:37:03 ruggedcom kernel: xnsynch_release_thread: BP: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 0, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: lo: rescnt: 1, switched: 1 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 2, switched: 0 >>>> Jan 10 10:37:03 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> Jan 10 10:37:04 ruggedcom kernel: hi: rescnt: 3, switched: 0 >>>> >>>> >>>> root@domain.hid:~# ./a.out 0 1 >>>> Spawning: tasks >>>> bP: 0, cp: 0, mode: 0 >>>> Acquire complete >>>> Release complete >>>> bP: 0, cp: 0, mode: 0 >>>> Acquire complete >>>> Release complete >>>> bP: 0, cp: 0, mode: 0 >>>> Acquire complete >>>> ^C >>>> >>>> >>>> Rgds, >>>> Mak. >>>> >>>> >>>> >>>> On 10/01/12 10:26 AM, Makarand Pradhan wrote: >>>>> Hi Phillippe, >>>>> >>>>> You are right. Task 1 requires to be started with prio 0. I start >>>>> seeing >>>>> the problem after task2 grabs the mutex and releases them. The first >>>>> task never jumps back to seconodary. Here is my output. The mode never >>>>> goes back to 0 after "Grabbing mux in HP" and the rescnt stays >>>>> stuck at >>>>> 1 in the kernel. >>>>> >>>>> root@domain.hid:~# ./relax 0 1 >>>>> Spawning: tasks >>>>> bP: 0, cp: 0, mode: 0 >>>>> Acquire complete >>>>> Release complete >>>>> bP: 0, cp: 0, mode: 0 >>>>> Acquire complete >>>>> Release complete >>>>> bP: 0, cp: 0, mode: 0 >>>>> Acquire complete >>>>> Release complete >>>>> bP: 0, cp: 0, mode: 0 >>>>> Acquire complete >>>>> Grabbing mux in HP >>>>> Mux held by Task2 >>>>> Release complete >>>>> bP: 0, cp: 0, mode: 1 >>>>> Acquire complete >>>>> Release complete >>>>> bP: 0, cp: 0, mode: 1 >>>>> Acquire complete >>>>> >>>>> Rgds, >>>>> Mak. >>>>> >>>>> >>>>> On 10/01/12 10:11 AM, Philippe Gerum wrote: >>>>>> On 01/09/2012 09:50 PM, Makarand Pradhan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360. >>>>>>> >>>>>>> I am noticing an issue while using the auto relax feature related to >>>>>>> mutexes. I am using nested mutexes. The code is attached to this >>>>>>> email. >>>>>>> >>>>>>> The problem is that I am not relaxing after a RT thread grabs and >>>>>>> releases a mutex. On further investigation, it was noted that the >>>>>>> rescnt >>>>>>> is not going down to 0. >>>>>> From your code, task1 would auto-relax only if started with >>>>>> priority 0, >>>>>> which is what I get here: >>>>>> >>>>>> -bash-3.2# ./relax 0 1 >>>>>> Spawning: tasks >>>>>> bP: 0, cp: 0, mode: 0 >>>>>> Acquire complete >>>>>> Release complete >>>>>> bP: 0, cp: 0, mode: 0 >>>>>> Acquire complete >>>>>> Release complete >>>>>> bP: 0, cp: 0, mode: 0 >>>>>> Acquire complete >>>>>> Release complete >>>>>> ... >>>>>> >>>>>> Conversely, I get the right behavior if setting a non-zero >>>>>> priority to >>>>>> task1: >>>>>> >>>>>> -bash-3.2# ./relax 1 0 >>>>>> Spawning: tasks >>>>>> bP: 1, cp: 1, mode: 1 >>>>>> Acquire complete >>>>>> Release complete >>>>>> bP: 1, cp: 1, mode: 1 >>>>>> Acquire complete >>>>>> Release complete >>>>>> bP: 1, cp: 1, mode: 1 >>>>>> Acquire complete >>>>>> ... >>>>>> >>>>>> In any case, the priority of task2 should have no impact on the >>>>>> result. >>>>>> >>>>>> I'm running current 2.6 HEAD commit (168da46de), kernel >>>>>> 3.1.5/powerpc32 >>>>>> (52xx), pipeline 2.13-06. >>>>>> >>>>>> Which priority arguments are you passing to your test program? >>>>>> >>>>>>> Another observation is that I do not hit >>>>>>> rt_mutex_release in the kernel in the problem scenario, I believe >>>>>>> when >>>>>>> the thread undergoes a priority inversion.This may be a problem >>>>>>> as the >>>>>>> rescnt would not get decremented. Not sure how the mutex is >>>>>>> releasing >>>>>>> wiithout hitting rt_mutex_relase or am I missing anything? >>>>>>> >>>>>> These are fast mutexes, the thread does not have to jump to kernel >>>>>> space >>>>>> unless the released mutex was actually contented. >>>>>> >>>>>>> If I have both the tasks running at priority 0, I stay in the >>>>>>> secondary >>>>>>> domain, rt_mutex_release is invoked as expected, the rescnt goes >>>>>>> down to >>>>>>> 0 when all the mutexes are released. >>>>>>> >>>>>>> Has anyone faced this problem? >>>>>>> >>>>>> I'm unsure there is any yet. Auto-relax applies to non -rt Xenomai >>>>>> threads only (i.e. prio == 0). >>>>>> >>>>>>> Rgds, >>>>>>> Makarand >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xenomai-help mailing list >>>>>>> Xenomai-help@domain.hid >>>>>>> https://mail.gna.org/listinfo/xenomai-help >>>> >>> >> > > -- Philippe.