Messages in this thread | | | Date | Sun, 28 Feb 1999 20:05:05 +1100 | From | Richard Gooch <> | Subject | Re: 2.2.2: 2 thumbs up from lm |
| |
yodaiken@chelm.cs.nmt.edu writes: > > > 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 > > ?
Erm, I don't quite see why you're asking about example user code. Unless you thought I meant that dropping RT was done in user code? That's not what I meant. I meant that inside the kernel you drop RT and pick up up again later.
Otherwise I'm missing the point.
> > > 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.
As expected. But since at least some of the applications I care about are light/well-controlled load, it's fine.
Regards,
Richard....
- 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/
| |