All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Michal Hocko <mhocko@suse.com>
Cc: hughd@google.com, xuyu@linux.alibaba.com,
	akpm@linux-foundation.org, mgorman@suse.de, aarcange@redhat.com,
	willy@infradead.org, linux-kernel@vger.kernel.org,
	kernel-team@fb.com, linux-mm@kvack.org, vbabka@suse.cz
Subject: Re: [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified
Date: Mon, 30 Nov 2020 09:40:01 -0500	[thread overview]
Message-ID: <0bf4037559563bd51f6ac68d659e9f886387fa7e.camel@surriel.com> (raw)
In-Reply-To: <20201130100053.GD17338@dhcp22.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Mon, 2020-11-30 at 11:00 +0100, Michal Hocko wrote:
> On Fri 27-11-20 14:03:39, Rik van Riel wrote:
> > On Fri, 2020-11-27 at 08:52 +0100, Michal Hocko wrote:
> > > On Thu 26-11-20 13:04:14, Rik van Riel wrote:
> > > > I would be more than happy to implement things differently,
> > > > but I am not sure what alternative you are suggesting.
> > > 
> > > Simply do not alter gfp flags? Or warn in some cases of a serious
> > > mismatch.
> > > E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL
> > > users
> > > of
> > > shmem.
> > 
> > Not altering the gfp flags is not really an option,
> > because that would leads to attempting to allocate THPs
> > with GFP_HIGHUSER, which is what is used to allocate
> > regular tmpfs pages.
> 
> Right but that is a completely different reason to alter the mask and
> it
> would be really great to know whether this is a theoretical concern
> or
> those users simply do not ever use THPs. Btw. should they be using
> THPs
> even if they opt themselves into GFP_KERNEL restriction?

I suppose disabling THPs completely if the gfp_mask
passed to shmem_getpage_gfp() is not GFP_HIGHUSER
is another option.

That seems like it might come with its own pitfalls,
though, both functionality wise and maintenance wise.

Does anyone have
strong feelings between "limit gfp_mask"
and "disable THP for !GFP_HIGHUSER"?

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-11-30 14:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 19:49 [PATCH v6 0/3] mm,thp,shm: limit shmem THP alloc gfp_mask Rik van Riel
2020-11-24 19:49 ` [PATCH 1/3] mm,thp,shmem: " Rik van Riel
2020-11-26 16:56   ` Vlastimil Babka
2020-11-27  8:15   ` Michal Hocko
2020-11-24 19:49 ` [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified Rik van Riel
2020-11-26 13:40   ` Michal Hocko
2020-11-26 18:04     ` Rik van Riel
2020-11-26 18:04       ` Rik van Riel
2020-11-27  7:52       ` Michal Hocko
2020-11-27 19:03         ` Rik van Riel
2020-11-27 19:03           ` Rik van Riel
2020-11-30 10:00           ` Michal Hocko
2020-11-30 14:40             ` Rik van Riel [this message]
2020-11-30 14:40               ` Rik van Riel
2020-11-24 19:49 ` [PATCH 3/3] mm,thp,shmem: make khugepaged obey tmpfs mount flags Rik van Riel
2020-11-26 17:18   ` Vlastimil Babka
2020-11-26 18:14     ` Rik van Riel
2020-11-26 18:14       ` Rik van Riel
2020-11-26 19:42       ` Vlastimil Babka
2020-11-26 20:14         ` Rik van Riel
2020-11-26 20:14           ` Rik van Riel
2020-12-14 21:16 ` [PATCH v6 0/3] mm,thp,shm: limit shmem THP alloc gfp_mask Hugh Dickins
2020-12-14 21:16   ` Hugh Dickins
2020-12-14 22:20   ` Andrew Morton
2020-12-14 22:52   ` Vlastimil Babka
2021-02-24  8:41     ` Hugh Dickins
2021-02-24  8:41       ` Hugh Dickins
2021-02-24 14:46       ` Rik van Riel
2021-02-24 14:46         ` Rik van Riel
2021-02-24 16:55         ` Hugh Dickins
2021-02-24 16:55           ` Hugh Dickins
2021-02-24 17:10           ` [PATCH 4/3] mm,shmem,thp: limit shmem THP allocations to requested zones Rik van Riel
2021-02-26 12:34             ` Vlastimil Babka

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=0bf4037559563bd51f6ac68d659e9f886387fa7e.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=xuyu@linux.alibaba.com \
    /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.