From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4FBCAFC8.5060608@xenomai.org> Date: Wed, 23 May 2012 11:37:12 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <4FBBBA25.5010308@mind.be> <4FBBECA0.4020502@xenomai.org> <4FBCA055.9060607@mind.be> <4FBCA398.7030705@xenomai.org> In-Reply-To: <4FBCA398.7030705@xenomai.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] CPU occupation without context switches? List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnout Vandecappelle Cc: xenomai@xenomai.org On 05/23/2012 10:45 AM, Philippe Gerum wrote: > On 05/23/2012 10:31 AM, Arnout Vandecappelle wrote: >> On 05/22/12 21:44, Philippe Gerum wrote: >>> On 05/22/2012 06:09 PM, Arnout Vandecappelle wrote: >>>> Hoi, >>>> >>>> After a few minutes of running my application, I see this: >>>> >>>> # cat /proc/xenomai/stat >>>> CPU PID MSW CSW PF STAT %CPU NAME >>>> 1 828 22 65 0 00300182 9.8 bench_RTnet_scope_thread_loop >>>> 1 839 2 46627538 0 00300186 53.8 bench_RTnet >>>> ... >>>> >>>> i.e. the bench_RTnet_scope_thread_loop takes 10% CPU but no >>>> context switches. How is this possible? I've looked at the >>>> source code and can't find an explanation: when the exectime >>>> accounting is updated, the csw is incremented as well (in >>>> __xnpod_schedule()). >>>> >>> >>> Unless your thread which seems to repeatedly attempt to pend on some >>> sync object has its wait condition satisfied on >>> entry to the syscall most of the time, which may cause >>> __xnpod_schedule() to leave it running without incrementing the >>> switch count. >> >> It is indeed possible that my application does something like that. But >> wouldn't the switch count be incremented every time the bench_RTnet >> thread >> is executed? That thread runs at 20kHz and at higher priority so it >> should >> pre-empt the other one, which should lead to context switches in the >> _loop >> thread. > > 20Khz does not put much pressure on mid/high end x86, so I believe > bench_RTnet does not preempt the loop thread that much actually, but the > latter does consume most of the 500 us time slot without suspending, > with the former switching in in the remaining quantum most of the time > (i.e. not preempting any other RT thread). Except that 20Khz means a 50 us time slot, not 500 us. This leaves much less opportunity for the explanation above to stand up. What is the typical latency of your system? > >> >> Unfortunately, I can't reproduce the situation anymore... If I can I'll >> try with Xenomai 2.6.0. >> >> >> Regards, >> Arnout >> > > -- Philippe.