Messages in this thread | | | Date | Sun, 26 Jul 2009 20:03:43 +0100 | From | Jamie Lokier <> | Subject | Re: report a bug about sched_rt |
| |
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
| |