Philippe Gerum wrote:
> On Thu, 2006-06-29 at 12:48 +0200, Philippe Gerum wrote:
> > > > Switching off priority adjustment for the root thread before moving a
> > > > SCHED_FIFO shadow to SCHED_OTHER would prevent this side-effect. We'd
> > > > need to add a per-thread status bit to check wheth
On Thu, 2006-06-29 at 12:48 +0200, Philippe Gerum wrote:
> > > Switching off priority adjustment for the root thread before moving a
> > > SCHED_FIFO shadow to SCHED_OTHER would prevent this side-effect. We'd
> > > need to add a per-thread status bit to check whether we should run
> > > xnpod_renic
Jan Kiszka wrote:
> (..)
> Now I wonder how to resolve this, how to make pthread_setschedparam (a
> rather central RT-service) really real-time safe? I would say we need
> something like a lazy schedparam propagation to Linux which only takes
> place when the thread enters secondary mode inten
Philippe Gerum wrote:
> On Thu, 2006-06-29 at 12:48 +0200, Philippe Gerum wrote:
>> On Thu, 2006-06-29 at 12:34 +0200, Jan Kiszka wrote:
>>> Philippe Gerum wrote:
On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
>> ...
>> The pthread is blocked on the irqben
On Thu, 2006-06-29 at 12:48 +0200, Philippe Gerum wrote:
> On Thu, 2006-06-29 at 12:34 +0200, Jan Kiszka wrote:
> > Philippe Gerum wrote:
> > > On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
> > >> Jan Kiszka wrote:
> > >>> ...
> > >>> The pthread is blocked on the irqbench device ioctl. On h
On Thu, 2006-06-29 at 12:34 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
> >> Jan Kiszka wrote:
> >>> ...
> >>> The pthread is blocked on the irqbench device ioctl. On hitting ^C,
> >>> close() is invoked from the main thread for that dev
Philippe Gerum wrote:
> On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> ...
>>> The pthread is blocked on the irqbench device ioctl. On hitting ^C,
>>> close() is invoked from the main thread for that device. The pthread is
>>> woken up and obviously relaxed on some li
On Thu, 2006-06-29 at 11:24 +0200, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > ...
> > The pthread is blocked on the irqbench device ioctl. On hitting ^C,
> > close() is invoked from the main thread for that device. The pthread is
> > woken up and obviously relaxed on some linux syscall (after being
Jan Kiszka wrote:
> ...
> The pthread is blocked on the irqbench device ioctl. On hitting ^C,
> close() is invoked from the main thread for that device. The pthread is
> woken up and obviously relaxed on some linux syscall (after being
> interrupted twice by the periodic timer event of a "latency -
Jan Kiszka wrote:
> Hi,
>
> could someone give this scenario a try (requires my recent patch series)
> and tell me if you are also seeing excessive latencies:
>
> Start:
> irqloop (+xeno_irqbench) -P 99 -t 0
> latency -p 200 -P 50
>
> Terminate:
> irqloop
>
> The termination seems to cause high
Hi,
could someone give this scenario a try (requires my recent patch series)
and tell me if you are also seeing excessive latencies:
Start:
irqloop (+xeno_irqbench) -P 99 -t 0
latency -p 200 -P 50
Terminate:
irqloop
The termination seems to cause high latencies to the (then highest-prio)
period
11 matches
Mail list logo
