From: Matthew Wilcox <willy@infradead.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: linux-mm@kvack.org
Subject: Re: [RFC 00/11] Remove 'order' argument from many mm functions
Date: Tue, 14 May 2019 07:51:30 -0700 [thread overview]
Message-ID: <20190514145130.GD3721@bombadil.infradead.org> (raw)
In-Reply-To: <20190509110755.v4dzyophpaoinqhr@box>
On Thu, May 09, 2019 at 02:07:55PM +0300, Kirill A. Shutemov wrote:
> On Mon, May 06, 2019 at 09:05:58PM -0700, Matthew Wilcox wrote:
> > Anyway, this is just a quick POC due to me being on an aeroplane for
> > most of today. Maybe we don't want to spend five GFP bits on this.
> > Some bits of this could be pulled out and applied even if we don't want
> > to go for the main objective. eg rmqueue_pcplist() doesn't use its
> > gfp_flags argument.
>
> I like the idea. But I'm somewhat worried about running out of bits in
> gfp_t. Is there anything preventing us to bump gfp_t to u64 in the future?
It's stored in a few structs that might not appreciate it growing,
like struct address_space. I've been vaguely wondering about how to
combine order, gfp_t and nodeid into one parameter in a way that doesn't
grow those structs, but I don't have a solid idea yet.
prev parent reply other threads:[~2019-05-14 14:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 4:05 [RFC 00/11] Remove 'order' argument from many mm functions Matthew Wilcox
2019-05-07 4:05 ` [PATCH 01/11] fix function alignment Matthew Wilcox
2019-05-09 10:55 ` Kirill A. Shutemov
2019-05-07 4:06 ` [PATCH 02/11] mm: Pass order to __alloc_pages_nodemask in GFP flags Matthew Wilcox
2019-05-09 1:50 ` Ira Weiny
2019-05-09 13:58 ` Matthew Wilcox
2019-05-09 16:22 ` Weiny, Ira
2019-05-09 10:59 ` Kirill A. Shutemov
2019-05-07 4:06 ` [PATCH 03/11] mm: Pass order to __get_free_pages() " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 04/11] mm: Pass order to prep_new_page " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 05/11] mm: Remove gfp_flags argument from rmqueue_pcplist Matthew Wilcox
2019-05-07 4:06 ` [PATCH 06/11] mm: Pass order to rmqueue in GFP flags Matthew Wilcox
2019-05-07 4:06 ` [PATCH 07/11] mm: Pass order to get_page_from_freelist " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 08/11] mm: Pass order to __alloc_pages_cpuset_fallback " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 09/11] mm: Pass order to prepare_alloc_pages " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 10/11] mm: Pass order to try_to_free_pages " Matthew Wilcox
2019-05-07 4:06 ` [PATCH 11/11] mm: Pass order to node_reclaim() " Matthew Wilcox
2019-05-09 1:58 ` [RFC 00/11] Remove 'order' argument from many mm functions Ira Weiny
2019-05-09 14:07 ` Matthew Wilcox
2019-05-09 16:48 ` Weiny, Ira
2019-05-09 18:29 ` Matthew Wilcox
2019-05-29 21:44 ` Ira Weiny
2019-05-09 11:07 ` Kirill A. Shutemov
2019-05-14 14:51 ` Matthew Wilcox [this message]
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=20190514145130.GD3721@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.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.