Messages in this thread | | | Date | Mon, 30 Aug 1999 00:09:51 -0600 | From | yodaiken@chelm ... | Subject | Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency), see testresults ,but ISDN troubles |
| |
On Mon, Aug 30, 1999 at 08:55:45AM +0200, Ingo Molnar wrote: > > Tell me what I misunderstood. As far as I can tell, pre patch behavior > > involves many fewer calls to schedule, post patch behavior for a write, for > > example, can make at least one extra call to the scheduler for every block > > copied. [...] > > the thing is, we are simply getting what we asked for. In that benchmark
so what happens if we ask for more than one thing?
> we have a soundcard-using RT program that gets ~1000 reschedules a second > and 'wastes' CPU cycles (artificially) after every reschedule. The first > benchmark config used an unmodified kernel that has simply violated the > (very tight, 1msec) RT constraints of the RT process. Then we had a kernel > modified by lowlatency-N6+patches, which kernel correctly satisfied the RT > process' requests and rescheduled to it (and away from it) about every > msec or so. No wonder IMO that disk performance might suffer if such tight > RT constraints are satisfied accurately. Do you see my point? Disk > performance does not suffer if 'simple' CPU-using processes are running.
I don't see how your code avoids reschedules from non SCHED_FIFO/RR processes. And I'm not convinced tha even then, it is reasonable to allow this. But first explain why a screen saver will not trigger the same behavior. The screen saver will do fast writes to the screen, and these will trigger io for X and for the saver itself. Both operations will set needs_resched. So we expect io performance to get worse in this case. Right?
> > > [...] New > > behavior: a screen saver, which is small i/o bound, causes needs resched > > to be set continually, and the write is segmented into many smaller writes. > > do you see where you missed the point? We are talking about _RT, CPU-using > high-frequency rescheduling_ processes that cause a measured bandwith > difference. Not screen savers. Not 'simple' CPU hogs. RT processes.
I know that that is your intention, but I don't understand how you expect to limit the effects of the changes to RT tasks. That's why I ask for Lmbench data and also database benchmarks.
By the way, I don't mean to be too critical here - this is very important work and if we had millisecond soft rt tasks in Linux, it would really be useful for RTLinux too -- people ask for it all the time. My caution is that simply adding new premption points to the kernel is not simple and has far reaching effects.
- 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/
| |