linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	Laura Abbott <labbott@redhat.com>,
	 "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	 Michal Hocko <mhocko@suse.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Roman Gushchin <guro@fb.com>,  Minchan Kim <minchan@kernel.org>,
	Rik van Riel <riel@surriel.com>,
	 Christian Koenig <christian.koenig@amd.com>,
	Huang Rui <ray.huang@amd.com>,
	 Eric Biederman <ebiederm@xmission.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Pavel Machek <pavel@ucw.cz>,
	 kernel-team@lge.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v2 05/10] mm/gup: separate PageHighMem() and PageHighMemZone() use case
Date: Mon, 4 May 2020 12:02:52 +0900	[thread overview]
Message-ID: <CAAmzW4NERJeiVsekHFicbH2v4BMQprUsHe+9U+T4JvMMOMB=PA@mail.gmail.com> (raw)
In-Reply-To: <20200501122427.GB21897@infradead.org>

2020년 5월 1일 (금) 오후 9:24, Christoph Hellwig <hch@infradead.org>님이 작성:
>
> On Wed, Apr 29, 2020 at 12:26:38PM +0900, js1304@gmail.com wrote:
> > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >
> > Until now, PageHighMem() is used for two different cases. One is to check
> > if there is a direct mapping for this page or not. The other is to check
> > the zone of this page, that is, weather it is the highmem type zone or not.
> >
> > Now, we have separate functions, PageHighMem() and PageHighMemZone() for
> > each cases. Use appropriate one.
> >
> > Note that there are some rules to determine the proper macro.
> >
> > 1. If PageHighMem() is called for checking if the direct mapping exists
> > or not, use PageHighMem().
> > 2. If PageHighMem() is used to predict the previous gfp_flags for
> > this page, use PageHighMemZone(). The zone of the page is related to
> > the gfp_flags.
> > 3. If purpose of calling PageHighMem() is to count highmem page and
> > to interact with the system by using this count, use PageHighMemZone().
> > This counter is usually used to calculate the available memory for an
> > kernel allocation and pages on the highmem zone cannot be available
> > for an kernel allocation.
> > 4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
> > is just copy of the previous PageHighMem() implementation and won't
> > be changed.
> >
> > I apply the rule #2 for this patch.
> >
> > Acked-by: Roman Gushchin <guro@fb.com>
> > Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > ---
> >  mm/gup.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/gup.c b/mm/gup.c
> > index 11fda53..9652eed 100644
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -1608,7 +1608,7 @@ static struct page *new_non_cma_page(struct page *page, unsigned long private)
> >        */
> >       gfp_t gfp_mask = GFP_USER | __GFP_NOWARN;
> >
> > -     if (PageHighMem(page))
> > +     if (PageHighMemZone(page))
> >               gfp_mask |= __GFP_HIGHMEM;
>
> I think this wants to stay PageHighMem.  This migrates CMA pages to
> other places before doing a long term pin.  Anything that didn't have
> a direct mapping before won't need one for the new page, which could
> also include non-highmem zones without a highmem mapping.

What we want to do here is to guess allocation gfp flags of original
page in order to allocate
a new page with most relaxed gfp flag. It is depend on the zone where
the page belong to
rather than existence of direct mapping. Until now, existence of
direct mapping implies
the type of zone so there is no problem.

After my future CMA patchset, direct mapped CMA page will be on the
ZONE_MOVABLE.
And, a page on ZONE_MOVABLE should be allocated with __GFP_HIGHMEM |
__GFP_MOVABLE.
So, most relaxed gfp flag for this CMA page would include
__GFP_HIGHMEM. If PageHighMem()
is used here, __GFP_HIGHMEM would be lost since this CMA page has a
direct mapping.

Therefore, PageHighMemZone() is right one here.

Anyway, I saw Eric's comment in other e-mail that abstraction is
needed to guess gfp flags of
original page and I agree with it. This site can also get benefit of
such a change.

Thanks.


  reply	other threads:[~2020-05-04  3:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29  3:26 [PATCH v2 00/10] change the implementation of the PageHighMem() js1304
2020-04-29  3:26 ` [PATCH v2 01/10] mm/page-flags: introduce PageHighMemZone() js1304
2020-04-29  3:26 ` [PATCH v2 02/10] drm/ttm: separate PageHighMem() and PageHighMemZone() use case js1304
2020-04-29  3:26 ` [PATCH v2 03/10] kexec: " js1304
2020-05-01 14:03   ` Eric W. Biederman
2020-05-04  3:10     ` Joonsoo Kim
2020-05-04 14:03       ` Eric W. Biederman
2020-05-04 21:59         ` [RFC][PATCH] kexec: Teach indirect pages how to live in high memory Eric W. Biederman
2020-05-05 17:44           ` Hari Bathini
2020-05-05 18:39             ` Eric W. Biederman
2020-10-09  1:35               ` Joonsoo Kim
2020-05-06  5:23         ` [PATCH v2 03/10] kexec: separate PageHighMem() and PageHighMemZone() use case Joonsoo Kim
2020-04-29  3:26 ` [PATCH v2 04/10] power: " js1304
2020-05-01 12:22   ` Christoph Hellwig
2020-05-04  3:01     ` Joonsoo Kim
2020-04-29  3:26 ` [PATCH v2 05/10] mm/gup: " js1304
2020-05-01 12:24   ` Christoph Hellwig
2020-05-04  3:02     ` Joonsoo Kim [this message]
2020-04-29  3:26 ` [PATCH v2 06/10] mm/hugetlb: " js1304
2020-05-01 12:26   ` Christoph Hellwig
2020-05-04  3:03     ` Joonsoo Kim
2020-04-29  3:26 ` [PATCH v2 07/10] mm: " js1304
2020-05-01 12:30   ` Christoph Hellwig
2020-05-04  3:08     ` Joonsoo Kim
2020-04-29  3:26 ` [PATCH v2 08/10] mm/page_alloc: correct the use of is_highmem_idx() js1304
2020-04-29  3:26 ` [PATCH v2 09/10] mm/migrate: replace PageHighMem() with open-code js1304
2020-04-29  3:26 ` [PATCH v2 10/10] mm/page-flags: change the implementation of the PageHighMem() js1304
2020-04-30  1:47 ` [PATCH v2 00/10] " Andrew Morton
2020-05-01 10:52   ` Joonsoo Kim
2020-05-01 10:55     ` Christoph Hellwig
2020-05-01 12:15       ` Joonsoo Kim
2020-05-01 12:34         ` Christoph Hellwig
2020-05-04  3:09           ` Joonsoo Kim

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='CAAmzW4NERJeiVsekHFicbH2v4BMQprUsHe+9U+T4JvMMOMB=PA@mail.gmail.com' \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=christian.koenig@amd.com \
    --cc=ebiederm@xmission.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@lge.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=ray.huang@amd.com \
    --cc=riel@surriel.com \
    --cc=rjw@rjwysocki.net \
    --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).