On Fri, 2005-01-28 at 10:34 -0800, George Anzinger wrote:
> If you can use a machine that has a local apic we can leave the PIT out of
> it.
> Really this is MUCH preferred. If your box has a LAPIC, make sure it is not
> disabled by your config setup.
Unfortunately its an embedded box w/o
* George Anzinger wrote:
> The primary thing needed for this is a simple and quick way to switch
> a tasks priority, both from outside and from the task itself.
check out sched.c's mutex_setprio(p, prio) and mutex_getprio(p), which
is used by the PI code in kernel/rt.c. It's pretty robust and
* George Anzinger wrote:
> A quick comment here on the current RT code. It looks to me like
> there is a race in timer delivery. It looks like the softirq is
> "raised" by the PIT interrupt code and the jiffie is bumped by the
> timer thread. If the softirq gets to run prior to the PIT
Ingo Molnar wrote:
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
or is it that we have a 'group' of normal timers expiring, which, if
they happen to occur _just_ prior a HRT event will generate a larger
delay?
Yep. The timers expire at random times. So it's likely to have short
sequences of timer
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > or is it that we have a 'group' of normal timers expiring, which, if
> > they happen to occur _just_ prior a HRT event will generate a larger
> > delay?
>
> Yep. The timers expire at random times. So it's likely to have short
> sequences of timer
On Fri, 2005-01-28 at 09:24 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > > is this due to algorithmic/PIT-programming overhead, or due to the noise
> > > introduced by other, non-hard-RT timers? I'd guess the later from the
> > > looks of it, but did your test
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > is this due to algorithmic/PIT-programming overhead, or due to the noise
> > introduced by other, non-hard-RT timers? I'd guess the later from the
> > looks of it, but did your test introduce such noise (via networking and
> > application
On Fri, 2005-01-28 at 05:43 +0100, Ingo Molnar wrote:
> *
> is this due to algorithmic/PIT-programming overhead, or due to the noise
> introduced by other, non-hard-RT timers? I'd guess the later from the
> looks of it, but did your test introduce such noise (via networking and
> application
On Fri, 2005-01-28 at 05:43 +0100, Ingo Molnar wrote:
*
is this due to algorithmic/PIT-programming overhead, or due to the noise
introduced by other, non-hard-RT timers? I'd guess the later from the
looks of it, but did your test introduce such noise (via networking and
application
* Thomas Gleixner [EMAIL PROTECTED] wrote:
is this due to algorithmic/PIT-programming overhead, or due to the noise
introduced by other, non-hard-RT timers? I'd guess the later from the
looks of it, but did your test introduce such noise (via networking and
application workloads?).
On Fri, 2005-01-28 at 09:24 +0100, Ingo Molnar wrote:
* Thomas Gleixner [EMAIL PROTECTED] wrote:
is this due to algorithmic/PIT-programming overhead, or due to the noise
introduced by other, non-hard-RT timers? I'd guess the later from the
looks of it, but did your test introduce such
* Thomas Gleixner [EMAIL PROTECTED] wrote:
or is it that we have a 'group' of normal timers expiring, which, if
they happen to occur _just_ prior a HRT event will generate a larger
delay?
Yep. The timers expire at random times. So it's likely to have short
sequences of timer interrupts
Ingo Molnar wrote:
* Thomas Gleixner [EMAIL PROTECTED] wrote:
or is it that we have a 'group' of normal timers expiring, which, if
they happen to occur _just_ prior a HRT event will generate a larger
delay?
Yep. The timers expire at random times. So it's likely to have short
sequences of timer
* George Anzinger george@mvista.com wrote:
A quick comment here on the current RT code. It looks to me like
there is a race in timer delivery. It looks like the softirq is
raised by the PIT interrupt code and the jiffie is bumped by the
timer thread. If the softirq gets to run prior to
* George Anzinger george@mvista.com wrote:
The primary thing needed for this is a simple and quick way to switch
a tasks priority, both from outside and from the task itself.
check out sched.c's mutex_setprio(p, prio) and mutex_getprio(p), which
is used by the PI code in kernel/rt.c. It's
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Some numbers to make this more transparent.
>
> Machine: PIII Celeron 333MHz
> RT - T0: 1ms cyclic
> RT - T1: 2ms cyclic
>
>
> Load average is ~4.0 for all tests. The numbers are maximum deviation
> from the timeline in microseconds. Test
Hi,
some thoughts and observations.
I'm running -RT + a port of UTIME (the grandfather of HRT, IIRC) on a
couple of machines (x86,ppc,arm - all UP) here.
One part of the problem is the gettimeofday() issue, which seems to be
already addressed by John Stulz's patches.
The more interresting
Hi,
some thoughts and observations.
I'm running -RT + a port of UTIME (the grandfather of HRT, IIRC) on a
couple of machines (x86,ppc,arm - all UP) here.
One part of the problem is the gettimeofday() issue, which seems to be
already addressed by John Stulz's patches.
The more interresting
* Thomas Gleixner [EMAIL PROTECTED] wrote:
Some numbers to make this more transparent.
Machine: PIII Celeron 333MHz
RT - T0: 1ms cyclic
RT - T1: 2ms cyclic
Load average is ~4.0 for all tests. The numbers are maximum deviation
from the timeline in microseconds. Test time was ~60
19 matches
Mail list logo
