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/