All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <jweiner@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/7] mm: rework __isolate_lru_page() file/anon filter
Date: Sat, 03 Mar 2012 12:27:39 +0400	[thread overview]
Message-ID: <4F51D5FB.4050106@openvz.org> (raw)
In-Reply-To: <alpine.LSU.2.00.1203021542560.3578@eggly.anvils>

Hugh Dickins wrote:
> On Wed, 29 Feb 2012, Konstantin Khlebnikov wrote:
>
>> This patch adds file/anon filter bits into isolate_mode_t,
>> this allows to simplify checks in __isolate_lru_page().
>>
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>
> Almost-Acked-by: Hugh Dickins<hughd@google.com>
>
> with one whitespace nit, and one functional addition requested.
>
> I'm perfectly happy with your :?s myself, but some people do dislike
> them.  I'm happy with the switch alternative if it's as efficient:
> something that surprised me very much when trying to get convincing
> performance numbers for per-memcg per-zone lru_lock at home...
>
> ... __isolate_lru_page() featured astonishly high on the perf report
> of streaming from files on ext4 on /dev/ram0 to /dev/null, coming
> immediately below the obvious zeroing and copying: okay, the zeroing
> and copying were around 30% each, and __isolate_lru_page() down around
> 2% or below, but even so it seemed very odd that it should feature so
> high, and any optimizations to it very welcome - unless it was purely
> some bogus result.

Actually ANON/FILE ACTIVE/INACTIVE checks does not required at non-lumpy reclaim
(all pages are picked from right lru list) and compaction (it does not care).
But seems like removing these two bit-checks cannot give noticeable performance gain.

This patch can be postponed. It does not so important and
it does not share context with other patches in this set.

>
>> ---
>>   include/linux/mmzone.h |    4 ++++
>>   include/linux/swap.h   |    2 +-
>>   mm/compaction.c        |    5 +++--
>>   mm/vmscan.c            |   27 +++++++++++++--------------
>>   4 files changed, 21 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index eff4918..2fed935 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -193,6 +193,10 @@ struct lruvec {
>>   #define ISOLATE_UNMAPPED	((__force isolate_mode_t)0x8)
>>   /* Isolate for asynchronous migration */
>>   #define ISOLATE_ASYNC_MIGRATE	((__force isolate_mode_t)0x10)
>> +/* Isolate swap-backed pages */
>> +#define	ISOLATE_ANON		((__force isolate_mode_t)0x20)
>> +/* Isolate file-backed pages */
>> +#define	ISOLATE_FILE		((__force isolate_mode_t)0x40)
>
>  From the patch you can see that the #defines above yours used a
> space where you have used a tab: better to use a space as above.
>
>> @@ -375,7 +376,7 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
>>   			mode |= ISOLATE_ASYNC_MIGRATE;
>>
>>   		/* Try isolate the page */
>> -		if (__isolate_lru_page(page, mode, 0) != 0)
>> +		if (__isolate_lru_page(page, mode) != 0)
>>   			continue;
>
> I thought you were missing something there, but no, that's rather
> the case you are simplifying.  However...
>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index af6cfe7..1b70338 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -1520,6 +1511,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct mem_cgroup_zone *mz,
>>   		isolate_mode |= ISOLATE_UNMAPPED;
>>   	if (!sc->may_writepage)
>>   		isolate_mode |= ISOLATE_CLEAN;
>> +	if (file)
>> +		isolate_mode |= ISOLATE_FILE;
>> +	else
>> +		isolate_mode |= ISOLATE_ANON;
>
> Above here, under "if (sc->reclaim_mode&  RECLAIM_MODE_LUMPYRECLAIM)",
> don't you need
>
> 		isolate_mode |= ISOLATE_ACTIVE | ISOLATE_FILE | ISOLATE_ANON;
>
> now to reproduce the same "all_lru_mode" behaviour as before?

Yes, I missed this. Thanks.

>
> Hugh

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <jweiner@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/7] mm: rework __isolate_lru_page() file/anon filter
Date: Sat, 03 Mar 2012 12:27:39 +0400	[thread overview]
Message-ID: <4F51D5FB.4050106@openvz.org> (raw)
In-Reply-To: <alpine.LSU.2.00.1203021542560.3578@eggly.anvils>

Hugh Dickins wrote:
> On Wed, 29 Feb 2012, Konstantin Khlebnikov wrote:
>
>> This patch adds file/anon filter bits into isolate_mode_t,
>> this allows to simplify checks in __isolate_lru_page().
>>
>> Signed-off-by: Konstantin Khlebnikov<khlebnikov@openvz.org>
>
> Almost-Acked-by: Hugh Dickins<hughd@google.com>
>
> with one whitespace nit, and one functional addition requested.
>
> I'm perfectly happy with your :?s myself, but some people do dislike
> them.  I'm happy with the switch alternative if it's as efficient:
> something that surprised me very much when trying to get convincing
> performance numbers for per-memcg per-zone lru_lock at home...
>
> ... __isolate_lru_page() featured astonishly high on the perf report
> of streaming from files on ext4 on /dev/ram0 to /dev/null, coming
> immediately below the obvious zeroing and copying: okay, the zeroing
> and copying were around 30% each, and __isolate_lru_page() down around
> 2% or below, but even so it seemed very odd that it should feature so
> high, and any optimizations to it very welcome - unless it was purely
> some bogus result.

Actually ANON/FILE ACTIVE/INACTIVE checks does not required at non-lumpy reclaim
(all pages are picked from right lru list) and compaction (it does not care).
But seems like removing these two bit-checks cannot give noticeable performance gain.

This patch can be postponed. It does not so important and
it does not share context with other patches in this set.

>
>> ---
>>   include/linux/mmzone.h |    4 ++++
>>   include/linux/swap.h   |    2 +-
>>   mm/compaction.c        |    5 +++--
>>   mm/vmscan.c            |   27 +++++++++++++--------------
>>   4 files changed, 21 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index eff4918..2fed935 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -193,6 +193,10 @@ struct lruvec {
>>   #define ISOLATE_UNMAPPED	((__force isolate_mode_t)0x8)
>>   /* Isolate for asynchronous migration */
>>   #define ISOLATE_ASYNC_MIGRATE	((__force isolate_mode_t)0x10)
>> +/* Isolate swap-backed pages */
>> +#define	ISOLATE_ANON		((__force isolate_mode_t)0x20)
>> +/* Isolate file-backed pages */
>> +#define	ISOLATE_FILE		((__force isolate_mode_t)0x40)
>
>  From the patch you can see that the #defines above yours used a
> space where you have used a tab: better to use a space as above.
>
>> @@ -375,7 +376,7 @@ static isolate_migrate_t isolate_migratepages(struct zone *zone,
>>   			mode |= ISOLATE_ASYNC_MIGRATE;
>>
>>   		/* Try isolate the page */
>> -		if (__isolate_lru_page(page, mode, 0) != 0)
>> +		if (__isolate_lru_page(page, mode) != 0)
>>   			continue;
>
> I thought you were missing something there, but no, that's rather
> the case you are simplifying.  However...
>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index af6cfe7..1b70338 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -1520,6 +1511,10 @@ shrink_inactive_list(unsigned long nr_to_scan, struct mem_cgroup_zone *mz,
>>   		isolate_mode |= ISOLATE_UNMAPPED;
>>   	if (!sc->may_writepage)
>>   		isolate_mode |= ISOLATE_CLEAN;
>> +	if (file)
>> +		isolate_mode |= ISOLATE_FILE;
>> +	else
>> +		isolate_mode |= ISOLATE_ANON;
>
> Above here, under "if (sc->reclaim_mode&  RECLAIM_MODE_LUMPYRECLAIM)",
> don't you need
>
> 		isolate_mode |= ISOLATE_ACTIVE | ISOLATE_FILE | ISOLATE_ANON;
>
> now to reproduce the same "all_lru_mode" behaviour as before?

Yes, I missed this. Thanks.

>
> Hugh


  reply	other threads:[~2012-03-03  8:27 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29  9:15 [PATCH v4 ch1 0/7] mm: some cleanup/rework before lru_lock splitting Konstantin Khlebnikov
2012-02-29  9:15 ` Konstantin Khlebnikov
2012-02-29  9:15 ` [PATCH 1/7] mm/memcg: scanning_global_lru means mem_cgroup_disabled Konstantin Khlebnikov
2012-02-29  9:15   ` Konstantin Khlebnikov
2012-03-02  5:12   ` KAMEZAWA Hiroyuki
2012-03-02  5:12     ` KAMEZAWA Hiroyuki
2012-03-06 11:46     ` Glauber Costa
2012-03-06 11:46       ` Glauber Costa
2012-02-29  9:15 ` [PATCH 2/7] mm/memcg: move reclaim_stat into lruvec Konstantin Khlebnikov
2012-02-29  9:15   ` Konstantin Khlebnikov
2012-03-02  5:14   ` KAMEZAWA Hiroyuki
2012-03-02  5:14     ` KAMEZAWA Hiroyuki
2012-02-29  9:15 ` [PATCH 3/7] mm: rework __isolate_lru_page() file/anon filter Konstantin Khlebnikov
2012-02-29  9:15   ` Konstantin Khlebnikov
2012-03-02  5:17   ` KAMEZAWA Hiroyuki
2012-03-02  5:17     ` KAMEZAWA Hiroyuki
2012-03-02  5:51     ` Konstantin Khlebnikov
2012-03-02  5:51       ` Konstantin Khlebnikov
2012-03-02  8:17       ` KAMEZAWA Hiroyuki
2012-03-02  8:17         ` KAMEZAWA Hiroyuki
2012-03-02  8:53         ` Konstantin Khlebnikov
2012-03-02  8:53           ` Konstantin Khlebnikov
2012-03-06 11:57         ` Glauber Costa
2012-03-06 11:57           ` Glauber Costa
2012-03-06 12:53           ` Konstantin Khlebnikov
2012-03-06 12:53             ` Konstantin Khlebnikov
2012-03-03  0:22   ` Hugh Dickins
2012-03-03  0:22     ` Hugh Dickins
2012-03-03  8:27     ` Konstantin Khlebnikov [this message]
2012-03-03  8:27       ` Konstantin Khlebnikov
2012-03-03  9:20       ` Konstantin Khlebnikov
2012-03-03  9:20         ` Konstantin Khlebnikov
2012-03-03  9:16   ` [PATCH 3/7 v2] " Konstantin Khlebnikov
2012-03-03  9:16     ` Konstantin Khlebnikov
2012-03-05  0:27     ` KAMEZAWA Hiroyuki
2012-03-05  0:27       ` KAMEZAWA Hiroyuki
2012-03-07  3:22     ` Hugh Dickins
2012-03-07  3:22       ` Hugh Dickins
2012-03-08  5:30       ` KAMEZAWA Hiroyuki
2012-03-08  5:30         ` KAMEZAWA Hiroyuki
2012-03-09  2:06         ` Hugh Dickins
2012-03-09  2:06           ` Hugh Dickins
2012-03-09  7:16           ` Konstantin Khlebnikov
2012-03-09  7:16             ` Konstantin Khlebnikov
2012-03-10  0:04             ` Hugh Dickins
2012-03-10  0:04               ` Hugh Dickins
2012-03-10  6:55               ` Konstantin Khlebnikov
2012-03-10  6:55                 ` Konstantin Khlebnikov
2012-03-10  9:46                 ` Konstantin Khlebnikov
2012-03-10  9:46                   ` Konstantin Khlebnikov
2012-03-15  1:47                   ` Hugh Dickins
2012-03-15  1:47                     ` Hugh Dickins
2012-03-15  6:03                     ` Konstantin Khlebnikov
2012-03-15  6:03                       ` Konstantin Khlebnikov
2012-03-15 23:58                       ` Hugh Dickins
2012-03-15 23:58                         ` Hugh Dickins
2012-02-29  9:15 ` [PATCH 4/7] mm: push lru index into shrink_[in]active_list() Konstantin Khlebnikov
2012-02-29  9:15   ` Konstantin Khlebnikov
2012-03-02  5:21   ` KAMEZAWA Hiroyuki
2012-03-02  5:21     ` KAMEZAWA Hiroyuki
2012-03-03  0:24   ` Hugh Dickins
2012-03-03  0:24     ` Hugh Dickins
2012-02-29  9:15 ` [PATCH 5/7] mm: rework reclaim_stat counters Konstantin Khlebnikov
2012-02-29  9:15   ` Konstantin Khlebnikov
2012-03-02  5:28   ` KAMEZAWA Hiroyuki
2012-03-02  5:28     ` KAMEZAWA Hiroyuki
2012-03-02  6:11     ` Konstantin Khlebnikov
2012-03-02  6:11       ` Konstantin Khlebnikov
2012-03-02  8:03       ` KAMEZAWA Hiroyuki
2012-03-02  8:03         ` KAMEZAWA Hiroyuki
2012-02-29  9:16 ` [PATCH 6/7] mm/memcg: rework inactive_ratio calculation Konstantin Khlebnikov
2012-02-29  9:16   ` Konstantin Khlebnikov
2012-03-02  5:31   ` KAMEZAWA Hiroyuki
2012-03-02  5:31     ` KAMEZAWA Hiroyuki
2012-03-02  6:24     ` Konstantin Khlebnikov
2012-03-02  6:24       ` Konstantin Khlebnikov
2012-03-08  5:36       ` KAMEZAWA Hiroyuki
2012-03-08  5:36         ` KAMEZAWA Hiroyuki
2012-02-29  9:16 ` [PATCH 7/7] mm/memcg: use vm_swappiness from target memory cgroup Konstantin Khlebnikov
2012-02-29  9:16   ` Konstantin Khlebnikov
2012-03-02  5:32   ` KAMEZAWA Hiroyuki
2012-03-02  5:32     ` KAMEZAWA Hiroyuki

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=4F51D5FB.4050106@openvz.org \
    --to=khlebnikov@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=jweiner@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.