lkml.org 
[lkml]   [2010]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/8] vmscan: Do not writeback filesystem pages in direct reclaim
    On Wed, Jul 21, 2010 at 09:01:11PM +0900, KAMEZAWA Hiroyuki wrote:
    > > <SNIP>
    > >
    > > /*
    > > - * If we are direct reclaiming for contiguous pages and we do
    > > + * If specific pages are needed such as with direct reclaiming
    > > + * for contiguous pages or for memory containers and we do
    > > * not reclaim everything in the list, try again and wait
    > > - * for IO to complete. This will stall high-order allocations
    > > - * but that should be acceptable to the caller
    > > + * for IO to complete. This will stall callers that require
    > > + * specific pages but it should be acceptable to the caller
    > > */
    > > - if (nr_reclaimed < nr_taken && !current_is_kswapd() &&
    > > - sc->lumpy_reclaim_mode) {
    > > - congestion_wait(BLK_RW_ASYNC, HZ/10);
    > > + if (sc->may_writepage && !current_is_kswapd() &&
    > > + (sc->lumpy_reclaim_mode || sc->mem_cgroup)) {
    > > + int dirty_retry = MAX_SWAP_CLEAN_WAIT;
    >
    > Hmm, ok. I see what will happen to memcg.

    Thanks

    > But, hmm, memcg will have to select to enter this rounine based on
    > the result of 1st memory reclaim.
    >

    It has the option of igoring pages being dirtied but I worry that the
    container could be filled with dirty pages waiting for flushers to do
    something.

    > >
    > > - /*
    > > - * The attempt at page out may have made some
    > > - * of the pages active, mark them inactive again.
    > > - */
    > > - nr_active = clear_active_flags(&page_list, NULL);
    > > - count_vm_events(PGDEACTIVATE, nr_active);
    > > + while (nr_reclaimed < nr_taken && nr_dirty && dirty_retry--) {
    > > + wakeup_flusher_threads(laptop_mode ? 0 : nr_dirty);
    > > + congestion_wait(BLK_RW_ASYNC, HZ/10);
    > >
    >
    > Congestion wait is required ?? Where the congestion happens ?
    > I'm sorry you already have some other trick in other patch.
    >

    It's to wait for the IO to occur.

    > > - nr_reclaimed += shrink_page_list(&page_list, sc, PAGEOUT_IO_SYNC);
    > > + /*
    > > + * The attempt at page out may have made some
    > > + * of the pages active, mark them inactive again.
    > > + */
    > > + nr_active = clear_active_flags(&page_list, NULL);
    > > + count_vm_events(PGDEACTIVATE, nr_active);
    > > +
    > > + nr_reclaimed += shrink_page_list(&page_list, sc,
    > > + PAGEOUT_IO_SYNC, &nr_dirty);
    > > + }
    >
    > Just a question. This PAGEOUT_IO_SYNC has some meanings ?
    >

    Yes, in pageout it will wait on pages currently being written back to be
    cleaned before trying to reclaim them.

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


    \
     
     \ /
      Last update: 2010-07-21 16:29    [W:0.023 / U:32.856 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site