From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BC70920.9060002@domain.hid> Date: Thu, 15 Apr 2010 14:40:00 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4BB5B64B.6040803@domain.hid> <4BB5B7C1.4020301@domain.hid> <4BB5B874.5090904@domain.hid> <4BB5BA2D.1080604@domain.hid> <245373446233674495BCA5CA2FC1EB17378D015932@domain.hid> <4BBAD880.5040603@domain.hid> <20100415001912.GB26116@domain.hid> <1271328418.2365.622.camel@domain.hid> <20100415123607.GC26116@domain.hid> In-Reply-To: <20100415123607.GC26116@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] New scheduler class List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas Glatz Cc: "xenomai@xenomai.org" , Jan Kiszka Andreas Glatz wrote: > Hi, > > On Thu, Apr 15, 2010 at 06:46:58AM -0400, Philippe Gerum wrote: >> On Wed, 2010-04-14 at 20:19 -0400, Andreas Glatz wrote: >> >>> One thing I've noticed though, and this is not related to the patch (I verified it on a >>> vanilla Xenomai system): Consider the example I included. It prints average cycle times >>> and the cycle time variance of the high priority task ("T2"). I noticed a big difference >>> in the cycle time variance when switching the first task ("T1") to secondary mode with >>> rt_task_set_mode() and setting the scheduler policy to either SCHED_FIFO, SCHED_IDLE or >>> SCHED_NORMAL. I'm assuming someone asked this before and I didn't pay attention :) >>> Can someone give me a short explanation or point me somewhere to get an explanation for >>> this behaviour? I didn't expect such a difference in variance: >>> >> Moving back to secondary mode is nothing more than triggering the >> rescheduling procedure linux-wise, so the time credit for >> SCHED_OTHER/IDLE tasks decay as usual during your work loop, preemption >> by high priority task is more likely and so on. This variance is just >> the sign that those tasks cannot ask for more than what their scheduling >> policy grants. >> > > I think, I didn't express myself clearly enough. I was more puzzled about > the variance of the pure RT task (task w/o any secondary mode switches). > So it seems that changing the scheduling policy of the "relaxed" task has > an influence on the variance of the pure RT task. So the RT task seems > to wait for the "relaxed" task. But where exacly does it wait for it? Mmmmm... When waiting for the mutex? -- Gilles.