linux-kernel - Re: What's the relationship between Linux driver running priority and FIFO policy?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1277969774.1917.9.camel@laptop>
Date:	Thu, 01 Jul 2010 09:36:14 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Zhang, Yongchao (GE Healthcare)" <Yongchao.Zhang@...com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: What's the relationship between Linux driver running priority
 and FIFO policy?

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.
--
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/