Re: [PATCH] O11int for interactivity

From: Nick Piggin (piggin_at_cyberone.com.au)
Date: 08/05/03

  • Next message: Paul Blazejowski: "Re: Badness in device_release at drivers/base/core.c:84" 
    Date:	Tue, 05 Aug 2003 17:11:46 +1000
To: Andrew Morton <akpm@osdl.org>

    Andrew Morton wrote:

    >Valdis.Kletnieks@vt.edu wrote:
    >
    >>The *odd* part is that the pgpgin, pgpgout, and pswpin numbers do *NOT*
    >> seem to be correlated. High I/O loads from read/write don't seem to cause
    >> a problem - untarring the Linux distro won't do it, running badblocks won't do it.
    >>
    >> But if somebody has to swap out, all hell breaks loose...
    >>
    >
    >swapout tends to happen via page reclaim, whereas normal writeback does
    >not.
    >
    >What's the difference? When swapout is happening you can expect increased
    >latency in the page allocator.
    >
    >My guess is that xmms is getting throttled in try_to_free_pages().
    >
    >There is a very good argument for giving !SCHED_OTHER tasks "special
    >treatment" in the VM. ie:
    >
    >a) exempt them from balance_dirty_pages() throttling treatment altogether
    >
    >b) let them dip further into the page reserves in __alloc_pages.
    >
    >iirc, -aa kernels do some of this. As does the Digeo kernel. Just haven't
    >got around to it in 2.6. It's pretty simple.
    >
    >If xmms isn't running SCHED_FIFO/SCHED_RR, well, you lose.
    >
    >The instrumentation to add is page allocation latency.
    >
    >
    >Another possibility is that xmms is getting stuck in a read. The
    >anticipatory scheduler is currently rather tuned for throughput. Judging
    >by the vmstat trace which was posted, we have a classic
    >read-stream-vs-write-stream going on. We trade off latency versus
    >throughput; perhaps wrongly. You can decrease latency (at the expense of
    >throughput) by decreasing the settings in /sys/block/hda/queue/iosched.
    >
    >To a point, it is a nice linear tradeoff, and someone should put the time
    >in to tweak and characterise it.
    >
    >

    With 1 "big" writer if xmms submits a read, it should be serviced within
    50ms
    if there is no TCQ, possibly more, but likely to be less. The reading
    process
    should then be able to read for up to 200ms before writes are serviced
    again.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Paul Blazejowski: "Re: Badness in device_release at drivers/base/core.c:84"

    Relevant Pages

    • Re: Make pipe data structure be a circular list of pages, rather than
      ... Many latency critical apps use FIFO's for IPC; ... Ardour's GUI, control, and audio threads interact via a ... meaning "increased throughput albeit with more latency". ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: blk_congestion_wait racy?
      ... I am just preparing that mail :-) ... Roughly 400 MB of swapout. ... uses HZ/10 as timeout value. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • spurious remap_file_pages() -EINVAL
      ... As ->vm_private_data is used as a cursor for swapout of VM_NONLINEAR ... vmas, the check for NULL ->vm_private_data or VM_RESERVED is too ... This fixes an issue on 2.6.7-mm5 where system calls to remap_file_pages ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)