Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.32-6

[Steven Rostedt]

On Sat, 2004-12-11 at 18:59 +0100, Esben Nielsen wrote:
> On Fri, 10 Dec 2004, Steven Rostedt wrote:

> I am not sure I understand you correctly.
> 
> If it is a general method of making priority sorting on  wait-queues: Yes,
> certainly! The highest priority task nearly always ought to be woken
> first.
> 
> But in a lot of cases you send messages from high to low and visa verse
> without wanting to move their priorities by doing so. If forinstance you
> want a IRQ-thread to be increased in priority when a RT task listens to
> packets from that device I think it is a bad idea. The developer should
> himself set the priorities right. The device might use a lot of CPU in
> some cases. By increasing it's priority you might destroy the RT
> properties of all the tasks in between. In general you don't know.
>  

Actually, I was thinking of something more configurable (and so, more
complex).  The main problem I've seen in general, is to differentiate
services for RT tasks and others. So if a RT task is waiting for some
disk activity while other RT tasks are running, the IRQ thread (or
whatever will service the disk) may be starved. I agree that this is
really more of a design issue, but I thought that there may be ways to
facilitate the RT design by setting flags in a task before it reads from
disk, so in case the RT task blocks waiting for a disk read, the disk
serving thread would inherit the priority of that task. One could argue
that the task could simply increase the service provider's priority
before doing the read, but than it may not block, and this would be a
waist.

I guess servicing in general is very hard to predict, so a RT task must
have all its information read and stored somewhere that it can receive
in a predictable amount of time, and not on disk or someplace that takes
another task to do the request that handles other tasks as well (thus
complicating the priority scheme).  As for sockets, I did my Master's
thesis on setting up RT sockets that are handle separately from other
sockets with a protocol that allows for incoming packets to quickly be
determined that they are RT packets and can go right to where they are
needed. 

I just wanted to bring up this discussion, I guess a general approach is
too difficult and not worth the effort.

Thanks,

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