Re: [for -mm][PATCH][1/2] page reclaim throttle take3

["KOSAKI Motohiro" <kosaki.motohiro@jp.fujitsu.com>]

Hi Rik,

> On Sat, 22 Mar 2008 19:45:54 +0900
>  KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
>  > +     wait_event(zone->reclaim_throttle_waitq,
>  > +                atomic_add_unless(&zone->nr_reclaimers, 1,
>  > +                                  CONFIG_NR_MAX_RECLAIM_TASKS_PER_ZONE));
>
>  I like your patch, but can see one potential problem.   Sometimes
>  tasks that go into page reclaim with GFP_HIGHUSER end up recursing
>  back into page reclaim without __GFP_FS and/or __GFP_IO.
>
>  In that scenario, a task could end up waiting on itself and
>  deadlocking.

interesting point out.
but unfortunately I don't understand yet, sorry ;)

I think recursing reclaim doesn't happend because call graph is maked
as the following at that time.

  __alloc_pages_internal  (turn on PF_MEMALLOC)
    +- try_to_free_pages
        +- (skip)
            +- pageout
                +- (skip)
                    +-  __alloc_pages_internal

in second __alloc_pages_internal, PF_MEMALLOC populated.
thus bypassed try_to_free_pages.

Am I misunderstanding anything?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>