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

[Esben Nielsen]

On Sat, 11 Dec 2004, Steven Rostedt wrote:

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

Disk access - at least on top of a filesystem - is not real-time. But we
can say it is some other device.

I would take the following approach:
1) Ensure the IRQ handler isn't in anyway using a too much CPU and
increase it's priority staticly.
2) Reconsider my overall design: Apparently the device isn't suit-able for
real-time.

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

Linux relies on soft IRQ for delivering packets to the listening
protocol stacks. That is a problem because you can't just boost the
priority of soft-IRQ without boosting a lot of things.

With IRQ-threading the design could be changed such the IRQ thread does
the job directly. But that will make the whole IRQ thread drive the
protocol stack as well :-(

It all depends on what your requirements are. Maybe you can handle
"driving" the whole IP stack before handling the RT packet - maybe not.

How did you handle it in your thesis?


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

If you can think up something there is no harm in trying it :-)
 
> Thanks,
> 
> -- Steve
> 
Esben


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