linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Roman Gushchin <guro@fb.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	kernel-team@lge.com,  Vlastimil Babka <vbabka@suse.cz>,
	Christoph Hellwig <hch@infradead.org>,
	 Mike Kravetz <mike.kravetz@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	 Michal Hocko <mhocko@suse.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 01/11] mm/page_isolation: prefer the node of the source page
Date: Thu, 21 May 2020 10:18:40 +0900	[thread overview]
Message-ID: <CAAmzW4ND=AfXavSbraeWH2Pr-AQ=fTAiJFTBt66MrshMNEWuhA@mail.gmail.com> (raw)
In-Reply-To: <20200521003716.GA317575@carbon.dhcp.thefacebook.com>

2020년 5월 21일 (목) 오전 9:37, Roman Gushchin <guro@fb.com>님이 작성:
>
> On Mon, May 18, 2020 at 10:20:47AM +0900, js1304@gmail.com wrote:
> > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >
> > For locality, it's better to migrate the page to the same node
> > rather than the node of the current caller's cpu.
> >
> > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
> Acked-by: Roman Gushchin <guro@fb.com>

Thanks for review!

> > ---
> >  mm/page_isolation.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index 2c11a38..7df89bd 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -300,5 +300,7 @@ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
> >
> >  struct page *alloc_migrate_target(struct page *page, unsigned long private)
> >  {
> > -     return new_page_nodemask(page, numa_node_id(), &node_states[N_MEMORY]);
> > +     int nid = page_to_nid(page);
> > +
> > +     return new_page_nodemask(page, nid, &node_states[N_MEMORY]);
>
> Why not new_page_nodemask(page, page_to_nid(page), &node_states[N_MEMORY]) ?
> Still fits into 80 characters.

It's just my preference not directly using function call in argument
as much as possible.
If you don't like it, I will change it as you suggested. However,
since alloc_migrate_target()
will be removed in following patch, there will be no difference in the end.

Thanks.


  reply	other threads:[~2020-05-21  1:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18  1:20 [PATCH 00/11] clean-up the migration target allocation functions js1304
2020-05-18  1:20 ` [PATCH 01/11] mm/page_isolation: prefer the node of the source page js1304
2020-05-21  0:37   ` Roman Gushchin
2020-05-21  1:18     ` Joonsoo Kim [this message]
2020-05-27  6:45       ` Joonsoo Kim
2020-05-18  1:20 ` [PATCH 02/11] mm/migrate: move migration helper from .h to .c js1304
2020-05-21 18:17   ` Mike Kravetz
2020-05-18  1:20 ` [PATCH 03/11] mm/hugetlb: introduce alloc_control structure to simplify migration target allocation APIs js1304
2020-05-21  0:43   ` Roman Gushchin
2020-05-21  1:20     ` Joonsoo Kim
2020-05-21 18:57   ` Mike Kravetz
2020-05-22  5:52     ` Joonsoo Kim
2020-05-18  1:20 ` [PATCH 04/11] mm/hugetlb: unify hugetlb migration callback function js1304
2020-05-21  0:46   ` Roman Gushchin
2020-05-21  1:22     ` Joonsoo Kim
2020-05-21 20:54   ` Mike Kravetz
2020-05-22  7:38     ` Joonsoo Kim
2020-05-18  1:20 ` [PATCH 05/11] mm/hugetlb: make hugetlb migration target allocation APIs CMA aware js1304
2020-05-21 21:43   ` Mike Kravetz
2020-05-18  1:20 ` [PATCH 06/11] mm/hugetlb: do not modify user provided gfp_mask js1304
2020-05-21 22:19   ` Mike Kravetz
2020-05-22  7:42     ` Joonsoo Kim
2020-05-18  1:20 ` [PATCH 07/11] mm/migrate: change the interface of the migration target alloc/free functions js1304
2020-05-18  1:20 ` [PATCH 08/11] mm/migrate: make standard migration target allocation functions js1304
2020-05-18  1:20 ` [PATCH 09/11] mm/gup: use standard migration target allocation function js1304
2020-05-18  1:20 ` [PATCH 10/11] mm/mempolicy: " js1304
2020-05-18  1:20 ` [PATCH 11/11] mm/page_alloc: use standard migration target allocation function directly js1304

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='CAAmzW4ND=AfXavSbraeWH2Pr-AQ=fTAiJFTBt66MrshMNEWuhA@mail.gmail.com' \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).