Re: 2.2.2: 2 thumbs up from lm

yodaiken@chelm.cs.nmt.edu
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/