* [Xenomai-core] RFC: /proc/xenomai/latency change
@ 2010-09-25 15:30 Gilles Chanteperdrix
2010-09-25 17:27 ` Gilles Chanteperdrix
0 siblings, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2010-09-25 15:30 UTC (permalink / raw)
To: xenomai-core
Hi,
I have been working on omap3 performances, and during this, I noticed
one flaw in /proc/xenomai/latency: it displays the whole timer subsystem
anticipation whereas it should probably only allow setting the scheduler
latency. The reason is that when issuing the customary:
echo 0 > /proc/xenomai/latency
we were in fact also disabling any account of the timer programming
latency. This is probably almoste invisible on systems with low timer
programming latencies, but this turned out to account for around 5us
error on timer programming on omap. Now, the timer programming latency
is back to a more reasonable 1us on omap, but I still think we should
change this.
However, since it may break some users settings, I wonder if we should
apply it now or only in the 2.6 branch.
Here is the patch I am talking about:
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 7db0ccf..485dbef 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -3164,7 +3164,7 @@ static int latency_read_proc(char *page,
{
int len;
- len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency));
+ len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency) - nktimerlat);
len -= off;
if (len <= off + count)
*eof = 1;
@@ -3196,7 +3196,7 @@ static int latency_write_proc(struct file *file,
if ((*end != '\0' && !isspace(*end)) || ns < 0)
return -EINVAL;
- nklatency = xnarch_ns_to_tsc(ns);
+ nklatency = xnarch_ns_to_tsc(ns + nktimerlat);
return count;
}
--
Gilles.
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [Xenomai-core] RFC: /proc/xenomai/latency change
2010-09-25 15:30 [Xenomai-core] RFC: /proc/xenomai/latency change Gilles Chanteperdrix
@ 2010-09-25 17:27 ` Gilles Chanteperdrix
2010-09-27 12:18 ` Philippe Gerum
0 siblings, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2010-09-25 17:27 UTC (permalink / raw)
To: xenomai-core
Gilles Chanteperdrix wrote:
> Hi,
>
> I have been working on omap3 performances, and during this, I noticed
> one flaw in /proc/xenomai/latency: it displays the whole timer subsystem
> anticipation whereas it should probably only allow setting the scheduler
> latency. The reason is that when issuing the customary:
> echo 0 > /proc/xenomai/latency
>
> we were in fact also disabling any account of the timer programming
> latency. This is probably almoste invisible on systems with low timer
> programming latencies, but this turned out to account for around 5us
> error on timer programming on omap. Now, the timer programming latency
> is back to a more reasonable 1us on omap, but I still think we should
> change this.
>
> However, since it may break some users settings, I wonder if we should
> apply it now or only in the 2.6 branch.
>
> Here is the patch I am talking about:
Better:
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index 7db0ccf..2297b74 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -3164,7 +3164,7 @@ static int latency_read_proc(char *page,
{
int len;
- len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency));
+ len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency - nktimerlat));
len -= off;
if (len <= off + count)
*eof = 1;
@@ -3196,7 +3196,7 @@ static int latency_write_proc(struct file *file,
if ((*end != '\0' && !isspace(*end)) || ns < 0)
return -EINVAL;
- nklatency = xnarch_ns_to_tsc(ns);
+ nklatency = xnarch_ns_to_tsc(ns) + nktimerlat;
return count;
}
--
Gilles.
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [Xenomai-core] RFC: /proc/xenomai/latency change
2010-09-25 17:27 ` Gilles Chanteperdrix
@ 2010-09-27 12:18 ` Philippe Gerum
2010-09-27 12:37 ` Gilles Chanteperdrix
0 siblings, 1 reply; 5+ messages in thread
From: Philippe Gerum @ 2010-09-27 12:18 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core
On Sat, 2010-09-25 at 19:27 +0200, Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
> > Hi,
> >
> > I have been working on omap3 performances, and during this, I noticed
> > one flaw in /proc/xenomai/latency: it displays the whole timer subsystem
> > anticipation whereas it should probably only allow setting the scheduler
> > latency. The reason is that when issuing the customary:
> > echo 0 > /proc/xenomai/latency
> >
> > we were in fact also disabling any account of the timer programming
> > latency. This is probably almoste invisible on systems with low timer
> > programming latencies, but this turned out to account for around 5us
> > error on timer programming on omap. Now, the timer programming latency
> > is back to a more reasonable 1us on omap, but I still think we should
> > change this.
> >
> > However, since it may break some users settings, I wonder if we should
> > apply it now or only in the 2.6 branch.
> >
> > Here is the patch I am talking about:
>
> Better:
> diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
> index 7db0ccf..2297b74 100644
> --- a/ksrc/nucleus/pod.c
> +++ b/ksrc/nucleus/pod.c
> @@ -3164,7 +3164,7 @@ static int latency_read_proc(char *page,
> {
> int len;
>
> - len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency));
> + len = sprintf(page, "%Lu\n", xnarch_tsc_to_ns(nklatency - nktimerlat));
> len -= off;
> if (len <= off + count)
> *eof = 1;
> @@ -3196,7 +3196,7 @@ static int latency_write_proc(struct file *file,
> if ((*end != '\0' && !isspace(*end)) || ns < 0)
> return -EINVAL;
>
> - nklatency = xnarch_ns_to_tsc(ns);
> + nklatency = xnarch_ns_to_tsc(ns) + nktimerlat;
>
> return count;
> }
>
>
Fine with me. The nucleus should always know better regarding the timer
setup latency, so leaving it untouched by the /proc knob makes sense.
--
Philippe.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Xenomai-core] RFC: /proc/xenomai/latency change
2010-09-27 12:18 ` Philippe Gerum
@ 2010-09-27 12:37 ` Gilles Chanteperdrix
2010-09-27 12:47 ` Philippe Gerum
0 siblings, 1 reply; 5+ messages in thread
From: Gilles Chanteperdrix @ 2010-09-27 12:37 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
Philippe Gerum wrote:
> Fine with me. The nucleus should always know better regarding the timer
> setup latency, so leaving it untouched by the /proc knob makes sense.
>
Ok. My concern was about user settings, but guaranteeing an ABI never
meant we had to maintain the latency over Xenomai revisions, that was
kind of silly.
--
Gilles.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Xenomai-core] RFC: /proc/xenomai/latency change
2010-09-27 12:37 ` Gilles Chanteperdrix
@ 2010-09-27 12:47 ` Philippe Gerum
0 siblings, 0 replies; 5+ messages in thread
From: Philippe Gerum @ 2010-09-27 12:47 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-core
On Mon, 2010-09-27 at 14:37 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > Fine with me. The nucleus should always know better regarding the timer
> > setup latency, so leaving it untouched by the /proc knob makes sense.
> >
>
> Ok. My concern was about user settings, but guaranteeing an ABI never
> meant we had to maintain the latency over Xenomai revisions, that was
> kind of silly.
>
It is even recommended to make it shorter over time.
--
Philippe.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-09-27 12:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-25 15:30 [Xenomai-core] RFC: /proc/xenomai/latency change Gilles Chanteperdrix
2010-09-25 17:27 ` Gilles Chanteperdrix
2010-09-27 12:18 ` Philippe Gerum
2010-09-27 12:37 ` Gilles Chanteperdrix
2010-09-27 12:47 ` Philippe Gerum
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.