lkml.org 
[lkml]   [2010]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 03/10] writeback: Do not congestion sleep if there are no congested BDIs or significant writeback
    On Mon, Sep 13, 2010 at 06:48:10PM +0900, Minchan Kim wrote:
    > >> > > > <SNIP>
    > >> > > > I'm not saying it is. The objective is to identify a situation where
    > >> > > > sleeping until the next write or congestion clears is pointless. We have
    > >> > > > already identified that we are not congested so the question is "are we
    > >> > > > writing a lot at the moment?". The assumption is that if there is a lot
    > >> > > > of writing going on, we might as well sleep until one completes rather
    > >> > > > than reclaiming more.
    > >> > > >
    > >> > > > This is the first effort at identifying pointless sleeps. Better ones
    > >> > > > might be identified in the future but that shouldn't stop us making a
    > >> > > > semi-sensible decision now.
    > >> > >
    > >> > > nr_bdi_congested is no problem since we have used it for a long time.
    > >> > > But you added new rule about writeback.
    > >> > >
    > >> >
    > >> > Yes, I'm trying to add a new rule about throttling in the page allocator
    > >> > and from vmscan. As you can see from the results in the leader, we are
    > >> > currently sleeping more than we need to.
    > >>
    > >> I can see the about avoiding congestion_wait but can't find about
    > >> (writeback < incative / 2) hueristic result.
    > >>
    > >
    > > See the leader and each of the report sections entitled
    > > "FTrace Reclaim Statistics: congestion_wait". It provides a measure of
    > > how sleep times are affected.
    > >
    > > "congest waited" are waits due to calling congestion_wait. "conditional waited"
    > > are those related to wait_iff_congested(). As you will see from the reports,
    > > sleep times are reduced overall while callers of wait_iff_congested() still
    > > go to sleep. The reports entitled "FTrace Reclaim Statistics: vmscan" show
    > > how reclaim is behaving and indicators so far are that reclaim is not hurt
    > > by introducing wait_iff_congested().
    >
    > I saw the result.
    > It was a result about effectiveness _both_ nr_bdi_congested and
    > (writeback < inactive/2).
    > What I mean is just effectiveness (writeback < inactive/2) _alone_.

    I didn't measured it because such a change means that wait_iff_congested()
    ignored BDI congestion. If we were reclaiming on a NUMA machine for example,
    it could mean that a BDI gets flooded with requests if we only checked the
    ratios of one zone if little writeback was happening in that zone at the
    time. It did not seem like a good idea to ignore congestion.

    > If we remove (writeback < inactive / 2) check and unconditionally
    > return, how does the behavior changed?
    >

    Based on just the workload Johannes sent, scanning and completion times both
    increased without any improvement in the scanning/reclaim ratio (a bad result)
    hence why this logic was introduced to back off where there is some
    writeback taking place even if the BDI is not congested.

    --
    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab


    \
     
     \ /
      Last update: 2010-09-13 12:11    [W:0.033 / U:31.100 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site