From: Dirk Eibach <eibach@domain.hid>
To: jan.kiszka@domain.hid
Cc: Xenomai help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] (WARNING!!! PGP with incorrect signature) Re: Time
Date: Fri, 17 Aug 2007 15:01:32 +0200 [thread overview]
Message-ID: <46C59C2C.201@domain.hid> (raw)
In-Reply-To: <46C59855.7030902@domain.hid>
jan.kiszka@domain.hid wrote:
> Dirk Eibach wrote:
>> gilles.chanteperdrix@xenomai.org wrote:
>>> On 8/17/07, Dirk Eibach <eibach@domain.hid> wrote:
>>>> gilles.chanteperdrix@xenomai.org wrote:
>>>>> Dirk Eibach wrote:
>>>>> > Hello,
>>>>> >
>>>>> > I'm wondering how long a rt_mutex_acquire is supposed to take on a PPC405
>>>>> > platform. I'm getting times about 50 usec here, which is too much for my
>>>>> > application. Is anything wrong in my kernel/xenomai configuration or is
>>>>> > this time to expected?
>>>>>
>>>>> How do you measure this ? Are you sure the mutex is free when you try to
>>>>> acquire it ?
>>>>>
>>>> I prepared a small testcase. It shows about 8.300 ticks, which is about 30
>>>> usec on my platform (266MHz).
>>> Did you try to call ppc_getcounter twice in a raw to measure the
>>> overhead of this function ?
>> Calling ppc_getcounter twice in a raw results in 116 ticks.
>
> Is that service RT-safe, means does it stay in user space and issue no
> Linux syscall? Maybe some of the PPC gurus can comment on this as well
> (/me is lacking comparative numbers).
This service should be RT-safe as it consists only of a few assembly
commands that read the timestamp counter (which is allowed from userspace).
>
> Besides this, you may want to try running the latency tracer on your
> scenario. xntrace_user_start() and xntrace_user_stop(0) would frame the
> path you want to measure, /proc/ipipe/trace/frozen will show its kernel
> side. For sure, that tool will increase the latency even more, but it
> may show better what goes on.
Here we go (start, acquire, stop):
I-pipe frozen back-tracing service on 2.6.18/ipipe-1.5-00
------------------------------------------------------------
Freeze: 2785703857177 cycles, Trace Points: 30 (+10)
+--------------- Hard IRQs ('|': locked)
| +- Delay flag ('+': > 1 us, '!': > 10 us)
| |
Type Time Function (Parent)
: func -49+ xnshadow_sys_trace (hisyscall_event)
: func -46 ipipe_trace_frozen_reset (xnshadow_sys_trace)
: func -45+ __ipipe_global_path_lock (ipipe_trace_frozen_reset)
:|begin -44+ __ipipe_global_path_lock (ipipe_trace_frozen_reset)
:|end -41+ __ipipe_global_path_unlock (ipipe_trace_frozen_reset)
:|begin -39+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|end -38+ __ipipe_dispatch_event (__ipipe_syscall_root)
: func -34+ __ipipe_syscall_root (DoSyscall)
: func -33+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|begin -31+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|end -30+ __ipipe_dispatch_event (__ipipe_syscall_root)
: func -29+ hisyscall_event (__ipipe_dispatch_event)
: func -27+ __rt_mutex_acquire (hisyscall_event)
: func -25+ xnregistry_fetch (__rt_mutex_acquire)
:|begin -24+ xnregistry_fetch (__rt_mutex_acquire)
:|func -22+ __ipipe_restore_pipeline_head (xnregistry_fetch)
:|end -20+ __ipipe_restore_pipeline_head (xnregistry_fetch)
: func -19+ rt_mutex_acquire (__rt_mutex_acquire)
:|begin -17+ rt_mutex_acquire (__rt_mutex_acquire)
:|func -15+ __ipipe_restore_pipeline_head (rt_mutex_acquire)
:|end -14+ __ipipe_restore_pipeline_head (rt_mutex_acquire)
:|begin -12+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|end -11+ __ipipe_dispatch_event (__ipipe_syscall_root)
: func -8+ __ipipe_syscall_root (DoSyscall)
: func -6+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|begin -5+ __ipipe_dispatch_event (__ipipe_syscall_root)
:|end -4+ __ipipe_dispatch_event (__ipipe_syscall_root)
: func -2+ hisyscall_event (__ipipe_dispatch_event)
: func -1+ xnshadow_sys_trace (hisyscall_event)
< freeze 0 xnshadow_sys_trace (hisyscall_event)
|begin 1 __ipipe_dispatch_event (__ipipe_syscall_root)
|end 3 __ipipe_dispatch_event (__ipipe_syscall_root)
func 55 __ipipe_syscall_root (DoSyscall)
func 57 __ipipe_dispatch_event (__ipipe_syscall_root)
|begin 58 __ipipe_dispatch_event (__ipipe_syscall_root)
|end 60 __ipipe_dispatch_event (__ipipe_syscall_root)
func 61 hisyscall_event (__ipipe_dispatch_event)
func 63 xnshadow_relax (hisyscall_event)
|begin 64 xnshadow_relax (hisyscall_event)
|func 66 schedule_linux_call (xnshadow_relax)
Cheers
--
Dirk Eibach
Entwicklung
Guntermann & Drunck GmbH Systementwicklung
next prev parent reply other threads:[~2007-08-17 13:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-17 12:13 [Xenomai-help] Time for rt_mutex_acquire Dirk Eibach
2007-08-17 12:45 ` Jan Kiszka
2007-08-17 13:01 ` Dirk Eibach [this message]
2007-08-17 14:36 ` [Xenomai-help] (WARNING!!! PGP with incorrect signature) Re: Time Jan Kiszka
-- strict thread matches above, loose matches on Subject: below --
2007-08-20 14:48 Fillod Stephane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46C59C2C.201@domain.hid \
--to=eibach@domain.hid \
--cc=jan.kiszka@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.