Re: Setting the priority of an IRQ thread

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 16 Jun 2009, Martin Shepherd wrote:
> Which is what I am trying to do.  I want the application thread that
> uses my driver to be able to set the priority of its interrupt to
> equal the priority of the calling thread.  The problem with calling
> sched_setscheduler directly from user-space, is figuring out the PID
> of the IRQ thread. First of all, I have multiple boards of the same
> type, such that looking in /proc/interrupts won't tell me which IRQ is
> being used by a given board. So I would have to implement an ioctl()
> anyway, just to query the IRQ from the device driver. Secondly, the
> PID of the corresponding IRQ thread changes each time that
> request_irq() is called, and then later freed. So searching for the
> IRQ thread couldn't be done by a wrapper script around the program.
>
> It seems much more friendly and efficient for my driver to provide
> applications with an ioctl that tells it to set the priority of its
> IRQ thread.

Wrong. That information is already available in sysfs and there is no
reason to use an ioctl for that. ioctls are neither friendly nor
efficient.

The only missing information is the thread id, which needs to
exposed. This is completely independent of a single driver and needs
to be implemented in a generic way.

> Note that none of this would be necessary if the IRQ thread of a
> device automatically inherited the priority of the highest priority
> realtime thread that has requested (and not yet free'd) its IRQ. Not
> doing so, leads to a form of priority inversion.

Eek. That's even more wrong. Why should the priority of a user task
influence the priority of a device driver irq thread ? That's a
question of policy and policies are set from user space. The kernel
merily provides the interfaces.

Also your claim that it leads to a form of priority inversion is not
necessarily true. I can see what you mean, but there are cases where
the high prio thread just wants an async notification from a driver
that something has changed. It maybe or maybe not required that this
information comes in with high prio. Again that's a question of policy
and needs to be decided by the system designer.

Also why do you claim that the user task requests/frees the drivers
irq ? That depends on the driver, i.e. if it is implemented to request
the irq on open(), and can not be generalized.

Thanks,

	tglx