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

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 2004-12-13 at 13:55 -0800, Bill Huey wrote:

> 
> One thing that I noticed in this thread is that even though you were talking
> about the mechanisms to support these features, it really needs some
> consideration as to how it's going to effect the stock kernel since you're
> really introduction a first-class threading object/concept into the system.
> That means changes to the scheduler, how QoS fits into this, etc...
> IMO, it's ultimately about QoS and that alone is a hot button since it's
> so invasive throughout the kernel.
> 

Is there any talk about Ingo's patch getting into the mainstream kernel?

> Creating a special threaded server object (thinking out loud) might be a
> good idea in that it could be attached to any arbitrary subsystem at will,
> assuming if that particular subsystem's logic permits this easily.
> 
> It's not a light topic and can certain require more folks pushing it. I'm
> very interested in getting something like this into Linux, but stability,
> latency regularity, contention are things that still need a lot of work.
>  
> > The packet queue was a heap queue sorted by priority. The parts of the
> > TCP/IP stack was broken up into sections. The receive thread would only
> > process the packet on top of the queue. At the end of the section, it
> > would check to see if the queue changed and then start processing the
> > packet on top, if a higher packet came in at that time.  So the packets
> > on the queue had a state attached to them.  When the packet eventually
> > made it to the process waiting, it was then handled by that process. So
> > if a process was waiting, the process would have been woken up and it
> > would handle the rest of the processing. Otherwise the receive thread
> > would do it up to where it can drop it off to the processes. I set the
> > packet to be once less priority of the process it was sent from and the
> > one it was going to.
> > 
> > The sending was done mostly by the process, but if it had to wait for
> > some reason, the sending thread would take over.
> > 
> > This was mostly academic in nature, but was a lot of fun and interesting
> > to see how results changed with different methods.
> 
> This is a good track to research casually since not that many people have
> done so, and so that the problem space is mapped in this particular kernel.
> With things like VoIP and relatives becoming popular, this is becoming
> more and more essential over time.
> 
> It's up to you, but I think this is a great track to pursue.. That's because
> if you don't do it, somebody else will... :)
> 

I'd love to keep up on it, but now I'm working on a contract that's
taking all of my time. I did this some time back using the TimeSys GPL
kernel.  Of course I didn't have the priority inheritance (it's a
proprietary module), but it was good for my needs.

The work I'm now doing may swing back into this field, and we'll see
what happens.  As I said earlier, this was very much academic and needs
lots of work. I did notice that the processors today make the TCP/IP
stack very fast, but the big improvement was the separate queue for
packets coming in and seeing right a way that they need to be processed
ahead of other packets, as well as other processes.

> bill
>