Re: [PATCH] vmscan: prevent background aging of anon page in no swap system

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Ying,

On Mon, Aug 30, 2010 at 6:23 AM, Ying Han <yinghan@xxxxxxxxxx> wrote:
> On Sun, Aug 29, 2010 at 1:03 PM, Rik van Riel <riel@xxxxxxxxxx> wrote:
>> On 08/29/2010 01:45 PM, Ying Han wrote:
>>
>>> There are few other places in vmscan where we check nr_swap_pages and
>>> inactive_anon_is_low. Are we planning to change them to use
>>> total_swap_pages
>>> to be consistent ?
>>
>> If that makes sense, maybe the check can just be moved into
>> inactive_anon_is_low itself?
>
> That was the initial patch posted, instead we changed to use
> total_swap_pages instead. How this patch looks:
>
> @@ -1605,6 +1605,9 @@ static int inactive_anon_is_low(struct zone
> *zone, struct scan_control *sc)
>  {
>        int low;
>
> +       if (total_swap_pages <= 0)
> +               return 0;
> +
>        if (scanning_global_lru(sc))
>                low = inactive_anon_is_low_global(zone);
>        else
> @@ -1856,7 +1859,7 @@ static void shrink_zone(int priority, struct zone *zone,
>         * Even if we did not try to evict anon pages at all, we want to
>         * rebalance the anon lru active/inactive ratio.
>         */
> -       if (inactive_anon_is_low(zone, sc) && nr_swap_pages > 0)
> +       if (inactive_anon_is_low(zone, sc))
>                shrink_active_list(SWAP_CLUSTER_MAX, zone, sc, priority, 0);
>
>        throttle_vm_writeout(sc->gfp_mask);
>
> --Ying
>
>>

I did it intentionally since inactive_anon_is_low have been used both
direct reclaim and background path. In this point, your patch could
make side effect in swap enabled system when swap is full.

I think we need aging in only background if system is swap full.
That's because if the swap space is full, we don't reclaim anon pages
in direct reclaim path with (nr_swap_pages < 0)  and even have been
not rebalance it until now.
I think direct reclaim path is important about latency as well as
reclaim's effectiveness.
So if you don't mind, I hope direct reclaim patch would be left just as it is.

-- 
Kind regards,
Minchan Kim

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]