Messages in this thread | | | From | yodaiken@chelm ... | Subject | Re: 2.2.2: 2 thumbs up from lm | Date | Sun, 28 Feb 1999 01:58:01 -0700 (MST) |
| |
> > 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". > > I've had some private discussions with Larry (he seems to like the > idea), where I scribbled some ideas on how to solve these > problems. The simplest is to just drop RT priority when entering the > kernel.
Can you show some example user code for this? I'm not sure I get how it would work
sched_setsched(RR..) loop do user stuff as Rt syscall -- drop out of rt drop back into rt goto loop
?
> > 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? > > I don't need to run it to tell you what will happen. The latency for > the RT thread will be screwed. But, you see, that's *not* a problem I > was trying to solve with the RT queue patch. I took pains to point out > that the RT queue patch would give more deterministic context switch > latencies *under certain conditions* (namely, a friendly system load). > I think this point got lost amidst the flaming.
My measurements show exceptional timing stability under very light load. And terrible under heavy/moderate load.
- 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/
| |