All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Joonsoo Kim <js1304@gmail.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, Christoph Hellwig <hch@infradead.org>,
	Roman Gushchin <guro@fb.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Michal Hocko <mhocko@suse.com>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/4] mm/page_alloc: fix non cma alloc context
Date: Fri, 17 Jul 2020 10:15:03 +0200	[thread overview]
Message-ID: <c2edfd71-eee5-3d73-a9ee-0c384a3440be@suse.cz> (raw)
In-Reply-To: <5a8b13d5-da40-7b1b-2968-e6701001cc0e@suse.cz>

On 7/17/20 10:10 AM, Vlastimil Babka wrote:
> On 7/17/20 9:29 AM, Joonsoo Kim wrote:
>> 2020년 7월 16일 (목) 오후 4:45, Vlastimil Babka <vbabka@suse.cz>님이 작성:
>>>
>>> On 7/16/20 9:27 AM, Joonsoo Kim wrote:
>>> > 2020년 7월 15일 (수) 오후 5:24, Vlastimil Babka <vbabka@suse.cz>님이 작성:
>>> >> >  /*
>>> >> >   * get_page_from_freelist goes through the zonelist trying to allocate
>>> >> >   * a page.
>>> >> > @@ -3706,6 +3714,8 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
>>> >> >       struct pglist_data *last_pgdat_dirty_limit = NULL;
>>> >> >       bool no_fallback;
>>> >> >
>>> >> > +     current_alloc_flags(gfp_mask, &alloc_flags);
>>> >>
>>> >> I don't see why to move the test here? It will still be executed in the
>>> >> fastpath, if that's what you wanted to avoid.
>>> >
>>> > I want to execute it on the fastpath, too. Reason that I moved it here
>>> > is that alloc_flags could be reset on slowpath. See the code where
>>> > __gfp_pfmemalloc_flags() is on. This is the only place that I can apply
>>> > this option to all the allocation paths at once.
>>>
>>> But get_page_from_freelist() might be called multiple times in the slowpath, and
>>> also anyone looking for gfp and alloc flags setup will likely not examine this
>>> function. I don't see a problem in having it in two places that already deal
>>> with alloc_flags setup, as it is now.
>> 
>> I agree that anyone looking alloc flags will miss that function easily. Okay.
>> I will place it on its original place, although we now need to add one
>> more place.
>> *Three places* are gfp_to_alloc_flags(), prepare_alloc_pages() and
>> __gfp_pfmemalloc_flags().
> 
> Hm the check below should also work for ALLOC_OOM|ALLOC_NOCMA then.
> 
> /* Avoid allocations with no watermarks from looping endlessly */
>    if (tsk_is_oom_victim(current) &&
>         (alloc_flags == ALLOC_OOM ||
>          (gfp_mask & __GFP_NOMEMALLOC)))
>             goto nopage;
> 
> Maybe it's simpler to change get_page_from_freelist() then. But document well.

But then we have e.g. should_reclaim_retry() which calls __zone_watermark_ok()
where ALLOC_CMA plays a role too, so that means we should have alloc_mask set up
correctly wrt ALLOC_CMA at the __alloc_pages_slowpath() level...

>> Thanks.
>> 
> 


  reply	other threads:[~2020-07-17  8:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15  5:05 [PATCH 1/4] mm/page_alloc: fix non cma alloc context js1304
2020-07-15  5:05 ` [PATCH 2/4] mm/gup: restrict CMA region by using allocation scope API js1304
2020-07-15  8:24   ` Michal Hocko
2020-07-17  7:46     ` Joonsoo Kim
2020-07-17  7:46       ` Joonsoo Kim
2020-07-17  8:26       ` Michal Hocko
2020-07-17  9:28         ` Joonsoo Kim
2020-07-17  9:28           ` Joonsoo Kim
2020-07-17 11:08           ` Michal Hocko
2020-07-15  5:05 ` [PATCH 3/4] mm/hugetlb: make hugetlb migration callback CMA aware js1304
2020-07-15  8:33   ` Michal Hocko
2020-07-15  9:51   ` Vlastimil Babka
2020-07-15  5:05 ` [PATCH 4/4] mm/gup: use a standard migration target allocation callback js1304
2020-07-15  8:36   ` Michal Hocko
2020-07-15  8:24 ` [PATCH 1/4] mm/page_alloc: fix non cma alloc context Vlastimil Babka
2020-07-16  7:27   ` Joonsoo Kim
2020-07-16  7:27     ` Joonsoo Kim
2020-07-16  7:45     ` Vlastimil Babka
2020-07-17  7:29       ` Joonsoo Kim
2020-07-17  7:29         ` Joonsoo Kim
2020-07-17  8:10         ` Vlastimil Babka
2020-07-17  8:15           ` Vlastimil Babka [this message]
2020-07-17  9:12             ` Joonsoo Kim
2020-07-17  9:12               ` Joonsoo Kim
2020-07-15  8:28 ` Michal Hocko
2020-07-17  8:32 ` David Laight
2020-07-17  9:14   ` Joonsoo Kim
2020-07-17  9:14     ` 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=c2edfd71-eee5-3d73-a9ee-0c384a3440be@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=guro@fb.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=js1304@gmail.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=stable@vger.kernel.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.