Re: [Xenomai-core] RFC: /proc/xenomai/latency change
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: /proc/xenomai/latency change
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: /proc/xenomai/latency change
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RFC: /proc/xenomai/latency change
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RFC: /proc/xenomai/latency change
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
