[lkml]   [2009]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Swappiness vs. mmap() and interactive response

    > On Tue, Apr 28, 2009 at 05:09:16PM +0800, Wu Fengguang wrote:
    > > The semi-drop-behind is a great idea for the desktop - to put just
    > > accessed pages to end of LRU. However I'm still afraid it vastly
    > > changes the caching behavior and wont work well as expected in server
    > > workloads - shall we verify this?
    > >
    > > Back to this big-cp-hurts-responsibility issue. Background write
    > > requests can easily pass the io scheduler's obstacles and fill up
    > > the disk queue. Now every read request will have to wait 10+ writes
    > > - leading to 10x slow down of major page faults.
    > >
    > > I reach this conclusion based on recent CFQ code reviews. Will bring up
    > > a queue depth limiting patch for more exercises..
    > We can muck with the I/O scheduler, but another thing to consider is
    > whether the VM should be more aggressively throttling writes in this
    > case; it sounds like the big cp in this case may be dirtying pages so
    > aggressively that it's driving other (more useful) pages out of the
    > page cache --- if the target disk is slower than the source disk (for
    > example, backing up a SATA primary disk to a USB-attached backup disk)
    > no amount of drop-behind is going to help the situation.
    > So that leaves three areas for exploration:
    > * Write-throttling
    > * Drop-behind
    > * background writes pushing aside foreground reads
    > Hmm, note that although the original bug reporter is running Ubuntu
    > Jaunty, and hence 2.6.28, this problem is going to get *worse* with
    > 2.6.30, since we have the ext3 data=ordered latency fixes which will
    > write out the any journal activity, and worse, any synchornous commits
    > (i.e., caused by fsync) will force out all of the dirty pages with
    > WRITE_SYNC priority. So with a heavy load, I suspect this is going to
    > be more of a VM issue, and especially figuring out how to tune more
    > aggressive write-throttling may be key here.

    firstly, I'd like to report my reproduce test result.

    test environment: no lvm, copy ext3 to ext3 (not mv), no change swappiness,
    CFQ is used, userland is Fedora10, mmotm(2.6.30-rc1 + mm patch),
    CPU opteronx4, mem 4G

    mouse move lag: not happend
    window move lag: not happend
    Mapped page decrease rapidly: not happend (I guess, these page stay in
    active list on my system)
    page fault large latency: happend (latencytop display >200ms)

    Then, I don't doubt vm replacement logic now.
    but I need more investigate.
    I plan to try following thing today and tommorow.

    - XFS
    - LVM
    - another io scheduler (thanks Ted, good view point)
    - Rik's new patch

     \ /
      Last update: 2009-04-29 07:53    [W:0.050 / U:2.176 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site