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.047 / U:295.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site