From: Jan Kiszka <jan.kiszka@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] timer optimisations
Date: Mon, 22 May 2006 12:46:47 +0200 [thread overview]
Message-ID: <44719697.4080408@domain.hid> (raw)
In-Reply-To: <447188F9.60905@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> while I originally only wanted to add timer abstraction to RTDM, I now
>> have patch series for xntimer pending on my box pushing this layer
>> closer to hrtimer.
>>
>> But before posting it for discussion (needs further testing anyway), I
>> have two questions regarding some minor though not totally uninteresting
>> optimisation possibilities:
>>
>> 1. Is calling xntimer_start() with value=XN_INFINITE a real use case?
>> It's not documented explicitly. The effect of such an invocation
>> looks a bit like xntimer_stop(), but I didn't find a real caller so
>> far to asses it's relevance.
>
> xnpod_start_timer() uses this property to start the host tick relay
> timer. If XNARCH_HOST_TICK is zero, then no relay is required, and the
> timer should remain passive.
I see, but there is likely some other way to achieve this.
The point I'm having in mind is heavy usage of xntimer_start, e.g. from
inside some timer handler. RTnet could become such a user one day when
we may migrate the TDMA scheduler from thread context to a timer handler.
>
>>
>> If it is not used and could rather be declared illegal, we could safe
>> the related code in the do_timer_start handlers.
>>
>
> Dunno. To do that, we would need to carefully inspect each and every
> caller, especially for the various skins, which implies to analyze the
> requirements of the mimicked API too.
For sure, but we will have to review and test some stuff anyway with my
patches. :)
>
>> 2. rthal_timer_program_shot() uses explicit rthal_local_irq_save_hw on
>> ia64 and i386. Given the head optimisation, IRQs should already be
>> disabled when calling this service. So, can this IRQ masking be made
>> depending on !CONFIG_XENO_OPT_PIPELINE_HEAD?
>>
>
> Yes.
Ok, will get integrated.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
prev parent reply other threads:[~2006-05-22 10:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-22 9:09 [Xenomai-core] timer optimisations Jan Kiszka
2006-05-22 9:48 ` Philippe Gerum
2006-05-22 10:46 ` Jan Kiszka [this message]
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=44719697.4080408@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=rpm@xenomai.org \
--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.