Re: report a bug about sched_rt

Jamie Lokier
2009-07-26T19:04:15Z

Bill Gatliff wrote:
> Jamie Lokier wrote:
> >I agree with communicting the desire explicitly to the scheduler.
> >
> >In the above example, the exact desire is "give me as much CPU as I
> >ask for, because my hardware servicing will be adversely but
> >non-fatally affected if you don't, and the amount of CPU needed to
> >service the hardware cannot be determined in advance, but prevent me
> >from blocking progress in the rest of the system by limiting my
> >exclusive ownership of the CPU".
> >
> >How do you propose to communicate that to the scheduler, if not by
> >something rather like RT-bandwidth with downgrading to SCHED_OTHER
> >when a policy limit is exceeded?
>
> This is a great real-world problem. And there's no one-size-fits-all
> answer, unfortunately.
>
> RT-bandwidth will give you the system behavior you are after, but it's a
> pretty blunt instrument.

I'm under the impression that RT-bandwidth will *not* give the above
system behaviour, and that is the whole reason for this thread.

> I'd consider putting some throttling in your interrupt handler that
> prevents it from running more than a certain amount of calculation per
> interrupt event.

There is no interrupt handler in my specification above...

> And perhaps it's looking at execution timestamps to
> determine how often it's running, and can therefore do a rough
> calculation of how much CPU it's eating. At least until threaded
> interrupt scheduling is widespread, a runaway interrupt handler is
> definitely an opportunity to hang up a system.

With threaded interrupt scheduling using RT priority, that opportunity
to hang the system is exactly the same.

Indeed, threaded interrupts are a good example of when you might want
a limit fraction of the CPU allocated to that thread at RT priority,
falling down to SCHED_OTHER if the handler needs to continue to run.
That is, in fact, how

> Tasklets

tasklets, bottom halves and things like that work :-)

[snip explanation of tasklets]
> That's often a decent way to deal with system overload, especially if it
> leaves the system functional enough to take some sort of "evasive
> action" like reverting to polled i/o, issuing a diagnostic message, or
> doing an orderly transition to a safe mode.

Polled I/O is good when this happens. You can revert to polled I/O
automatically without coding it explicitly in interrupt handlers, if
the scheduler provides appropriate support.

When a threaded interrupt (with RT priority, naturally) is run too
often, then you stop scheduling it as RT and bring it down to
SCHED_OTHER or lower, periodically allowing it to have a fair share of
the CPU when there are other runnable tasks. That's quite close to
polling I/O, without coding it explicitly in the device driver.

So RT-bandwidth would be nice for those threaded interrupts.

-- Jamie