Message-ID: <20090726190343.GB12916@shareable.org>
Date:	Sun, 26 Jul 2009 20:03:43 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	sen wang <wangsen.linux@...il.com>, mingo@...e.hu,
	akpm@...ux-foundation.org, kernel@...ivas.org, npiggin@...e.de,
	arjan@...radead.org, linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists