Re: 2.2.2: 2 thumbs up from lm
Sat, 27 Feb 1999 22:36:48 -0700 (MST)

> I have no problem with the RT-Linux concept. I've said before I think
> it's a fine idea. The reaction I've received from people is that it's
> an incomplete programming environment (i.e. lack of semaphores). I've

Just for the record. Jerry Epplin provided a fine semaphore package that has
shipped with RTLinux for over a year.

> Where I do agree with the criticisms is that using RT-Linux is hard,
> because it doesn't fit seamlessly into the Linux/Unix programming
> environment. You can't take standard POSIX RT code and have the POSIX
> RT threads be RT-Linux threads. You have to stuff around with loading
> modules and separating your code into co-routines: separate
> programmes. I'd like to see this changed.

Me too.

> Ideally, a thread could ask to become an RT-Linux thread (using
> sched_setscheduler()). I acknowledge this is hard to achieve, but it's
> what would make using RT-Linux so much easier. This is important for
> people who have a certain reluctance in the first place. [*]

The technical problem here is that the thread may want to use libc functions
that are incompatible with the RT side. For example, I can't see any way
for a RT thread to safely "malloc". What I think would be good would be
a "run_as_rt_thread( f,period)" call that would send a piece of code into
the RT world with some safeguards at link time to make sure "f" was ok.

> Well, I've given some of my suggestions. Lets take that further. The
> changes I proposed to the standard Linux scheduler do 2 things:
> - improve RT performance by isolating the run queues

Richard. Can you try the following test:
Run 1 program that does setcheduler and does this loop
do 1 million times
rtdsc and compute difference
compute average and worst case
print result

Then run program 2 while 1 is running
while(1) write(1,buffer,10000000);

Start netscape, run a tar cvf /dev/null /home or something

What does the sched patch do?

> Of course, we have to support the POSIX RT scheduling classes, so just
> removing them isn't really an option. But suppose instead my (perhaps
> unrealistic) idea mentioned above (*) was implemented so that a thread
> which asked for RT scheduling got *real* RT? Now that would be nice.

I think that this is both possible and useful. I'd like to move RT out
of Linux proper where possible.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at