lkml.org 
[lkml]   [1999]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.889 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site