From: Peter Zijlstra <peterz@infradead.org>
To: "Zhang, Yongchao (GE Healthcare)" <Yongchao.Zhang@ge.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: What's the relationship between Linux driver running priority and FIFO policy?
Date: Thu, 01 Jul 2010 09:36:14 +0200 [thread overview]
Message-ID: <1277969774.1917.9.camel@laptop> (raw)
In-Reply-To: <9BC2BBFFF6E8F04094DB58B805758CE406C039A7@SHAMLVEM01.e2k.ad.ge.com>
On Thu, 2010-07-01 at 13:21 +0800, Zhang, Yongchao (GE Healthcare)
wrote:
> Hi
> I have a question disturb me very much.
> You know linux FIFO policy is common,and also there are many drivers
> running in system,so
> which level are these drivers running on? If I have a progrom which
> priority is FIFO99, does it disturb the driver running?
> I want know which level does drivers running on? For example, driver
> running on FIFOXX? and how does linux schedule on this
> case?
>
Fully depends on what a driver is and what you expect it to. If part of
the driver consists of a (or multiple) kernel thread, and that thread
has lower priority than FIFO99 (very typical) then of course.
If the driver is a pure IRQ driven thingy, then no, since hardirq
context will still preempt any task context.
Of course, if whatever proglet is talking to the driver is running at a
lower priority, that will get starved and your driver might again not
make any progress because all its queues are filled (incomming) or empty
(outgoing).
In general having a FIFO99 task around that consumes unbounded amounts
of cpu time is not something that is healthy for the system and it not
something I can recommend.
The Real-Time classes (FIFO/RR) are designed for deterministic programs
with bounded runtime. Things like spinning in userspace are very bad for
a number of reasons (which nevertheless doesn't seem to stop people from
doing just that).
The only answer that I can give you is: don't do that.
As to how Linux schedules, the scheduler is concerned only with tasks;
it will run the highest priority FIFO/RR task available, if there are no
FIFO/RR tasks present it will run SCHED_OTHER tasks, for those it will
divide the remaining time fairly based on their nice value (which is
mapped to a weight).
Interrupts -- at a hardware level -- interrupt task context and are thus
always ran whenever they happen.
That's all, there's really nothing more to it.
prev parent reply other threads:[~2010-07-01 7:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 5:21 Zhang, Yongchao (GE Healthcare)
2010-07-01 7:36 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1277969774.1917.9.camel@laptop \
--to=peterz@infradead.org \
--cc=Yongchao.Zhang@ge.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome