linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Ying Han <yinghan@google.com>, Rik van Riel <riel@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Venkatesh Pallipadi <venki@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH] vmscan: prevent background aging of anon page in no swap system
Date: Tue, 31 Aug 2010 10:23:10 +0900	[thread overview]
Message-ID: <AANLkTin4-NomOoNFYCKgi7oE+MCUiC0o0ftAkOwLKez_@mail.gmail.com> (raw)
In-Reply-To: <20100831095140.87C7.A69D9226@jp.fujitsu.com>

On Tue, Aug 31, 2010 at 9:56 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> On Sun, Aug 29, 2010 at 5:18 PM, Minchan Kim <minchan.kim@gmail.com> wrote:
>> > Hi Ying,
>> >
>> > On Mon, Aug 30, 2010 at 6:23 AM, Ying Han <yinghan@google.com> wrote:
>> >> On Sun, Aug 29, 2010 at 1:03 PM, Rik van Riel <riel@redhat.com> 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.
>>
>> Minchan, I would prefer to make kswapd as well as direct reclaim to be
>> consistent if possible.
>> They both try to reclaim pages when system is under memory pressure,
>> and also do not make
>> much sense to look at anon lru if no swap space available. Either
>> because of no swapon or run
>> out of swap space.
>>
>> I think letting kswapd to age anon lru without free swap space is not
>> necessary neither. That leads
>> to my initial patch:
>>
>> @@ -1605,6 +1605,9 @@ static int inactive_anon_is_low(struct zone
>> *zone, struct scan_control *sc)
>>  {
>>        int low;
>>
>> +       if (nr_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);
>>
>> What do you think ?
>
> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>
>
> I think both Ying's and Minchan's opnion are right and makes sense.  however I _personally_
> like Ying version because 1) this version is simpler 2) swap full is very rarely event 3)
> no swap mounting is very common on HPC. so this version could have a chance to
> improvement hpc workload too.

I agree.

>
> In the other word, both avoiding unnecessary TLB flush and keeping proper page aging are
> performance matter. so when we are talking performance, we always need to think frequency
> of the event.

Ying's one and mine both has a same effect.
Only difference happens swap is full. My version maintains old
behavior but Ying's one changes the behavior. I admit swap full is
rare event but I hoped not changed old behavior if we doesn't find any
problem.
If kswapd does aging when swap full happens, is it a problem?
We have been used to it from 2.6.28.

If we regard a code consistency is more important than _unexpected_
result, Okay. I don't mind it. :)
But at least we should do more thing to make the patch to compile out
for non-swap configurable system.


>
> Anyway I'm very glad minchan who embedded developer pay attention server workload
> carefully. Very thanks.
>

Thanks for the good comment. KOSAKI. :)
-- 
Kind regards,
Minchan Kim

--
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>

  reply	other threads:[~2010-08-31  1:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-29 15:43 Minchan Kim
2010-08-29 15:49 ` Rik van Riel
2010-08-29 17:45 ` Ying Han
2010-08-29 20:03   ` Rik van Riel
2010-08-29 20:56     ` Ying Han
2010-08-29 21:23     ` Ying Han
2010-08-29 22:26       ` Rik van Riel
2010-08-30  0:18       ` Minchan Kim
2010-08-30  5:40         ` Ying Han
2010-08-30  6:16           ` Minchan Kim
2010-08-31  0:56             ` KOSAKI Motohiro
2010-08-31  1:10               ` Minchan Kim
2010-08-31  1:18                 ` KOSAKI Motohiro
2010-08-31  1:36                   ` Minchan Kim
2010-08-31  1:41                     ` KOSAKI Motohiro
2010-08-31  0:56           ` KOSAKI Motohiro
2010-08-31  1:23             ` Minchan Kim [this message]
2010-08-31  1:38               ` KOSAKI Motohiro
2010-08-31  2:02                 ` Minchan Kim
2010-08-31  2:09                   ` KOSAKI Motohiro
2010-08-31  3:47                     ` Minchan Kim
2010-08-31  2:30               ` Rik van Riel
2010-08-31  3:46                 ` Minchan Kim
2010-09-03 21:06 ` Andrew Morton
2010-09-03 21:23   ` Rik van Riel
2010-09-03 21:45   ` Ying Han
2010-09-03 21:47   ` Ying Han
2010-09-03 21:56     ` Andrew Morton
2010-09-04  1:12       ` Venkatesh Pallipadi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTin4-NomOoNFYCKgi7oE+MCUiC0o0ftAkOwLKez_@mail.gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=venki@google.com \
    --cc=yinghan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox