All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <chengang@emindsoft.com.cn>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, minchan@kernel.org, vbabka@suse.cz,
	mgorman@techsingularity.net, gi-oh.kim@profitbricks.com,
	opensource.ganesh@gmail.com, hughd@google.com,
	kirill.shutemov@linux.intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Chen Gang <gang.chen.5i5j@gmail.com>
Subject: Re: [PATCH] mm: migrate: Return false instead of -EAGAIN for dummy functions
Date: Tue, 20 Sep 2016 05:46:58 +0800	[thread overview]
Message-ID: <57E05CD2.5090408@emindsoft.com.cn> (raw)
In-Reply-To: <20160917154659.GA29145@dhcp22.suse.cz>

On 9/17/16 23:46, Michal Hocko wrote:
> On Sat 17-09-16 15:20:36, chengang@emindsoft.com.cn wrote:
> 
>> Also change their related pure Boolean function numamigrate_isolate_page.
> 
> this is not true. Just look at the current usage
> 
> 	migrated = migrate_misplaced_page(page, vma, target_nid);
> 	if (migrated) {
> 		page_nid = target_nid;
> 		flags |= TNF_MIGRATED;
> 	} else
> 		flags |= TNF_MIGRATE_FAIL;
> 
> and now take your change which changes -EAGAIN into false. See the
> difference? Now I didn't even try to understand why
> CONFIG_NUMA_BALANCING=n pretends a success but then in order to keep the
> current semantic your patch should return true in that path. So NAK from
> me until you either explain why this is OK or change it.
>

For me, it really need return false:

 - For real implementation, when do nothing, it will return false.

 - I assume that the input page already is in a node (although maybe my
   assumption incorrect), and migrate to the same node. When the real
   implementation fails (e.g. -EAGAIN 10 times), it still returns false.

 - Original dummy implementation always return -EAGAIN, And -EAGAIN in
   real implementation will trigger returning false, after 10 times.

 - After grep TNF_MIGRATE_FAIL and TNF_MIGRATED, we only use them in
   task_numa_fault in kernel/sched/fair.c for numa_pages_migrated and
   numa_faults_locality, I guess they are only used for statistics.

So for me the dummy implementation need return false instead of -EAGAIN.
 
> But to be honest I am not keen of this int -> bool changes much.
> Especially if they are bringing a risk of subtle behavior change like
> this patch. And without a good changelog explaining why this makes
> sense.
> 

If our original implementation already used bool, our this issue (return
-EAGAIN) would be avoided (compiler would help us to find this issue).


Thanks.
-- 
Chen Gang (e??a??)

Managing Natural Environments is the Duty of Human Beings.

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

WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <chengang@emindsoft.com.cn>
To: Michal Hocko <mhocko@kernel.org>
Cc: akpm@linux-foundation.org, minchan@kernel.org, vbabka@suse.cz,
	mgorman@techsingularity.net, gi-oh.kim@profitbricks.com,
	opensource.ganesh@gmail.com, hughd@google.com,
	kirill.shutemov@linux.intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Chen Gang <gang.chen.5i5j@gmail.com>
Subject: Re: [PATCH] mm: migrate: Return false instead of -EAGAIN for dummy functions
Date: Tue, 20 Sep 2016 05:46:58 +0800	[thread overview]
Message-ID: <57E05CD2.5090408@emindsoft.com.cn> (raw)
In-Reply-To: <20160917154659.GA29145@dhcp22.suse.cz>

On 9/17/16 23:46, Michal Hocko wrote:
> On Sat 17-09-16 15:20:36, chengang@emindsoft.com.cn wrote:
> 
>> Also change their related pure Boolean function numamigrate_isolate_page.
> 
> this is not true. Just look at the current usage
> 
> 	migrated = migrate_misplaced_page(page, vma, target_nid);
> 	if (migrated) {
> 		page_nid = target_nid;
> 		flags |= TNF_MIGRATED;
> 	} else
> 		flags |= TNF_MIGRATE_FAIL;
> 
> and now take your change which changes -EAGAIN into false. See the
> difference? Now I didn't even try to understand why
> CONFIG_NUMA_BALANCING=n pretends a success but then in order to keep the
> current semantic your patch should return true in that path. So NAK from
> me until you either explain why this is OK or change it.
>

For me, it really need return false:

 - For real implementation, when do nothing, it will return false.

 - I assume that the input page already is in a node (although maybe my
   assumption incorrect), and migrate to the same node. When the real
   implementation fails (e.g. -EAGAIN 10 times), it still returns false.

 - Original dummy implementation always return -EAGAIN, And -EAGAIN in
   real implementation will trigger returning false, after 10 times.

 - After grep TNF_MIGRATE_FAIL and TNF_MIGRATED, we only use them in
   task_numa_fault in kernel/sched/fair.c for numa_pages_migrated and
   numa_faults_locality, I guess they are only used for statistics.

So for me the dummy implementation need return false instead of -EAGAIN.
 
> But to be honest I am not keen of this int -> bool changes much.
> Especially if they are bringing a risk of subtle behavior change like
> this patch. And without a good changelog explaining why this makes
> sense.
> 

If our original implementation already used bool, our this issue (return
-EAGAIN) would be avoided (compiler would help us to find this issue).


Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

  reply	other threads:[~2016-09-19 21:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-17  7:20 [PATCH] mm: migrate: Return false instead of -EAGAIN for dummy functions chengang
2016-09-17  7:20 ` chengang
2016-09-17 15:46 ` Michal Hocko
2016-09-17 15:46   ` Michal Hocko
2016-09-19 21:46   ` Chen Gang [this message]
2016-09-19 21:46     ` Chen Gang
2016-09-20  8:09     ` Michal Hocko
2016-09-20  8:09       ` Michal Hocko
2016-09-20 22:06       ` Chen Gang
2016-09-20 22:06         ` Chen Gang
2016-09-21  8:11         ` Michal Hocko
2016-09-21  8:11           ` Michal Hocko
2016-09-21  8:13           ` Vlastimil Babka
2016-09-21  8:13             ` Vlastimil Babka
2016-09-25 13:59           ` Chen Gang
2016-09-25 13:59             ` Chen Gang

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=57E05CD2.5090408@emindsoft.com.cn \
    --to=chengang@emindsoft.com.cn \
    --cc=akpm@linux-foundation.org \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=gi-oh.kim@profitbricks.com \
    --cc=hughd@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=opensource.ganesh@gmail.com \
    --cc=vbabka@suse.cz \
    /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.