lkml.org 
[lkml]   [2010]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] vmscan: synchronous lumpy reclaim don't call congestion_wait()
    Date
    > Hi KOSAKI, 
    >
    > On Sun, Aug 01, 2010 at 06:12:47PM +0900, KOSAKI Motohiro wrote:
    > > rebased onto Wu's patch
    > >
    > > ----------------------------------------------
    > > From 35772ad03e202c1c9a2252de3a9d3715e30d180f Mon Sep 17 00:00:00 2001
    > > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    > > Date: Sun, 1 Aug 2010 17:23:41 +0900
    > > Subject: [PATCH] vmscan: synchronous lumpy reclaim don't call congestion_wait()
    > >
    > > congestion_wait() mean "waiting for number of requests in IO queue is
    > > under congestion threshold".
    > > That said, if the system have plenty dirty pages, flusher thread push
    > > new request to IO queue conteniously. So, IO queue are not cleared
    > > congestion status for a long time. thus, congestion_wait(HZ/10) is
    > > almostly equivalent schedule_timeout(HZ/10).
    > Just a nitpick.
    > Why is it a problem?
    > HZ/10 is upper bound we intended. If is is rahter high, we can low it.
    > But totally I agree on this patch. It would be better to remove it
    > than lowing.

    because all of _unnecessary_ sleep is evil. the problem is, congestion_wait()
    mean "wait until queue congestion will be cleared, iow, wait all of IO".
    but we want to wait until _my_ IO finished.

    So, if flusher thread conteniously push new IO into the queue, that makes
    big difference.

    Thanks.




    \
     
     \ /
      Last update: 2010-08-02 06:15    [W:0.038 / U:0.064 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site