linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Minchan Kim <minchan@kernel.org>, Mel Gorman <mgorman@suse.de>,
	Rik van Riel <riel@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>
Subject: Re: [RFC PATCH V2 0/4] Reducing parameters of alloc_pages* family of functions
Date: Fri, 5 Dec 2014 17:07:20 -0800	[thread overview]
Message-ID: <CA+55aFwvWk6twgBaevPrF5z_0Faetnh0L19ZokWLidiaAaUmQg@mail.gmail.com> (raw)
In-Reply-To: <1417809545-4540-1-git-send-email-vbabka@suse.cz>

On Fri, Dec 5, 2014 at 11:59 AM, Vlastimil Babka <vbabka@suse.cz> wrote:
> Hey all,
>
> this is a V2 of attempting something that has been discussed when Minchan
> proposed to expand the x86 kernel stack [1], namely the reduction of huge
> number of parameters that the alloc_pages* family and get_page_from_freelist()
> functions have.

So I generally like this, but looking at that "struct alloc_context",
one member kind of stands out: the "order" parameter doesn't fit in
with all the other members.

Most everything else is describing where or what kind of pages to work
with. The "order" in contrast, really is separate.

So conceptually, my reaction is that it looks like a good cleanup even
aside from the code/stack size reduction, but that the alloc_context
definition is a bit odd.

Quite frankly, I think the :"order" really fits much more closely with
"alloc_flags", not with the alloc_context. Because like alloc_flags,.
it really describes how we need to allocate things within the context,
I'd argue.

In fact, I think that the order could actually be packed with the
alloc_flags in a single register, even on 32-bit (using a single-word
structure, perhaps). If we really care about number of parameters.

I'd rather go for "makes conceptual sense" over "packs order in
because it kind of works" and we don't modify it".

Hmm?

                       Linus

--
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>

  parent reply	other threads:[~2014-12-06  1:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 19:59 Vlastimil Babka
2014-12-05 19:59 ` [PATCH 1/4] mm: set page->pfmemalloc in prep_new_page() Vlastimil Babka
2014-12-05 19:59 ` [RFC PATCH 2/4] mm, page_alloc: reduce number of alloc_pages* functions' parameters Vlastimil Babka
2014-12-05 19:59 ` [RFC PATCH 3/4] mm: reduce try_to_compact_pages parameters Vlastimil Babka
2014-12-05 19:59 ` [PATCH 4/4] mm: microoptimize zonelist operations Vlastimil Babka
2014-12-06  1:07 ` Linus Torvalds [this message]
2014-12-08  8:32   ` [RFC PATCH V2 0/4] Reducing parameters of alloc_pages* family of functions 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=CA+55aFwvWk6twgBaevPrF5z_0Faetnh0L19ZokWLidiaAaUmQg@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --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