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 LAPI
* 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 h
* 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 interr
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 i
* 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 int
* 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 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 workl
* 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
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 ques
10 matches
Mail list logo
