From: Dennis Zhou <dennisszhou@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
Daniel Borkmann <daniel@iogearbox.net>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] percpu: allow select gfp to be passed to underlying allocators
Date: Thu, 15 Feb 2018 17:17:14 -0600 [thread overview]
Message-ID: <20180215231714.GB79973@localhost> (raw)
In-Reply-To: <20180215214148.GV695913@devbig577.frc2.facebook.com>
Hi,
On Thu, Feb 15, 2018 at 01:41:48PM -0800, Tejun Heo wrote:
> On Thu, Feb 15, 2018 at 10:08:16AM -0600, Dennis Zhou wrote:
> > +/* the whitelisted flags that can be passed to the backing allocators */
> > +#define gfp_percpu_mask(gfp) (((gfp) & (__GFP_NORETRY | __GFP_NOWARN)) | \
> > + GFP_KERNEL)
>
> Isn't there just one place where gfp comes in from outside? If so,
> this looks like a bit of overkill. Can't we just filter there?
>
I agree, but it's also nice having a single place where flags can be
added or removed. The primary motivator was for the "| GFP_KERNEL", but
as suggested in the other patch this is getting removed. I guess I still
lean towards having it as it's explicit and helps gate both the balance
path and the user allocation path.
Thanks,
Dennis
--
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: Dennis Zhou <dennisszhou@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
Daniel Borkmann <daniel@iogearbox.net>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] percpu: allow select gfp to be passed to underlying allocators
Date: Thu, 15 Feb 2018 17:17:14 -0600 [thread overview]
Message-ID: <20180215231714.GB79973@localhost> (raw)
In-Reply-To: <20180215214148.GV695913@devbig577.frc2.facebook.com>
Hi,
On Thu, Feb 15, 2018 at 01:41:48PM -0800, Tejun Heo wrote:
> On Thu, Feb 15, 2018 at 10:08:16AM -0600, Dennis Zhou wrote:
> > +/* the whitelisted flags that can be passed to the backing allocators */
> > +#define gfp_percpu_mask(gfp) (((gfp) & (__GFP_NORETRY | __GFP_NOWARN)) | \
> > + GFP_KERNEL)
>
> Isn't there just one place where gfp comes in from outside? If so,
> this looks like a bit of overkill. Can't we just filter there?
>
I agree, but it's also nice having a single place where flags can be
added or removed. The primary motivator was for the "| GFP_KERNEL", but
as suggested in the other patch this is getting removed. I guess I still
lean towards having it as it's explicit and helps gate both the balance
path and the user allocation path.
Thanks,
Dennis
next prev parent reply other threads:[~2018-02-15 23:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-15 16:08 [PATCH 0/3] percpu: introduce no retry semantics and gfp passthrough Dennis Zhou
2018-02-15 16:08 ` Dennis Zhou
2018-02-15 16:08 ` [PATCH 1/3] percpu: match chunk allocator declarations with definitions Dennis Zhou
2018-02-15 16:08 ` Dennis Zhou
2018-02-15 16:39 ` Christopher Lameter
2018-02-15 16:39 ` Christopher Lameter
2018-02-15 16:08 ` [PATCH 2/3] percpu: add __GFP_NORETRY semantics to the percpu balancing path Dennis Zhou
2018-02-15 16:08 ` Dennis Zhou
2018-02-15 21:39 ` Tejun Heo
2018-02-15 21:39 ` Tejun Heo
2018-02-15 23:10 ` Dennis Zhou
2018-02-15 23:10 ` Dennis Zhou
2018-02-16 18:07 ` [PATCH v2 " Dennis Zhou
2018-02-16 18:07 ` Dennis Zhou
2018-02-15 16:08 ` [PATCH 3/3] percpu: allow select gfp to be passed to underlying allocators Dennis Zhou
2018-02-15 16:08 ` Dennis Zhou
2018-02-15 21:41 ` Tejun Heo
2018-02-15 21:41 ` Tejun Heo
2018-02-15 23:17 ` Dennis Zhou [this message]
2018-02-15 23:17 ` Dennis Zhou
2018-02-16 18:09 ` [PATCH v2 " Dennis Zhou
2018-02-16 18:09 ` Dennis Zhou
2018-02-18 13:33 ` Tejun Heo
2018-02-18 13:33 ` Tejun Heo
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=20180215231714.GB79973@localhost \
--to=dennisszhou@gmail.com \
--cc=cl@linux.com \
--cc=daniel@iogearbox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@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.