Re: report a bug about sched_rt
From: Bill Gatliff
Date: Mon Jul 27 2009 - 09:35:28 EST
Jamie Lokier wrote:
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 think I misspoke. What I meant to say is that RT-bandwidth will
(probably) prevent the hardware handler from eating 100% of the CPU.
But the system will suffer quite a, um, "discontinuity" when the
throttling happens.
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...
True. But in practice, I think such devices are typically
interrupt-driven at some level.
b.g.
--
Bill Gatliff
bgat@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/