Messages in this thread | | | From | yodaiken@chelm ... | Subject | Re: 2.2.2: 2 thumbs up from lm | Date | 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 rdtsc usleep(50000); rtdsc and compute difference compute average and worst case done 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 o
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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |