[lkml]   [1999]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:53    [W:0.024 / U:65.364 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site