From: Matthew Wilcox <willy@infradead.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org, Andy Lutomirski <luto@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: Use higher-order pages in vmalloc
Date: Wed, 21 Feb 2018 09:01:29 -0800 [thread overview]
Message-ID: <20180221170129.GB27687@bombadil.infradead.org> (raw)
In-Reply-To: <fff58819-d39d-3a8a-f314-690bcb2f95d7@intel.com>
On Wed, Feb 21, 2018 at 08:16:22AM -0800, Dave Hansen wrote:
> On 02/21/2018 07:42 AM, Matthew Wilcox wrote:
> > This prompted me to write a patch I've been meaning to do for a while,
> > allocating large pages if they're available to satisfy vmalloc. I thought
> > it would save on touching multiple struct pages, but it turns out that
> > the checking code we currently have in the free_pages path requires you
> > to have initialised all of the tail pages (maybe we can make that code
> > conditional ...)
>
> What the concept here? If we can use high-order pages for vmalloc() at
> the moment, we *should* use them?
Right. It helps with fragmentation if we can keep higher-order
allocations together.
> One of the coolest things about vmalloc() is that it can do large
> allocations without consuming large (high-order) pages, so it has very
> few side-effects compared to doing a bunch of order-0 allocations. This
> patch seems to propose removing that cool thing. Even trying the
> high-order allocation could kick off a bunch of reclaim and compaction
> that was not there previously.
Yes, that's one of the debatable things. It'd be nice to have a GFP
flag that stopped after calling get_page_from_freelist() and didn't try
to do compaction or reclaim.
> If you could take this an only _opportunistically_ allocate large pages,
> it could be a more universal win. You could try to make sure that no
> compaction or reclaim is done for the large allocation. Or, maybe you
> only try it if there are *only* high-order pages in the allocator that
> would have been broken down into order-0 *anyway*.
>
> I'm not sure it's worth it, though. I don't see a lot of folks
> complaining about vmalloc()'s speed or TLB impact.
No, I'm not sure it's worth it either, although Konstantin's mail
suggesting improvements in fork speed were possible by avoiding vmalloc
reminded me that I'd been meaning to give this a try.
--
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>
next prev parent reply other threads:[~2018-02-21 17:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 10:55 [PATCH 1/4] vmalloc: add vm_flags argument to internal __vmalloc_node() Konstantin Khlebnikov
2018-01-23 10:55 ` [PATCH 2/4] vmalloc: add __vmalloc_area() Konstantin Khlebnikov
2018-01-23 10:55 ` [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area() Konstantin Khlebnikov
2018-01-23 13:57 ` Konstantin Khlebnikov
2018-02-21 0:16 ` Andrew Morton
2018-02-21 7:23 ` Konstantin Khlebnikov
2018-02-21 16:35 ` Andy Lutomirski
2018-01-23 10:55 ` [PATCH 4/4] kernel/fork: add option to use virtually mapped stacks as fallback Konstantin Khlebnikov
2018-02-21 15:42 ` Use higher-order pages in vmalloc Matthew Wilcox
2018-02-21 16:11 ` Andy Lutomirski
2018-02-21 16:50 ` Matthew Wilcox
2018-02-21 16:16 ` Dave Hansen
2018-02-21 17:01 ` Matthew Wilcox [this message]
2018-02-22 6:59 ` Michal Hocko
2018-02-22 12:22 ` Matthew Wilcox
2018-02-22 13:36 ` Michal Hocko
2018-02-22 19:01 ` Andy Lutomirski
2018-02-22 19:19 ` Dave Hansen
2018-02-22 19:27 ` Andy Lutomirski
2018-02-22 19:36 ` Dave Hansen
2018-02-23 12:13 ` Michal Hocko
2018-03-01 18:16 ` Eric Dumazet
2018-02-21 12:24 ` [PATCH 1/4] vmalloc: add vm_flags argument to internal __vmalloc_node() Matthew Wilcox
2018-02-21 12:39 ` Andrey Ryabinin
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=20180221170129.GB27687@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hch@infradead.org \
--cc=khlebnikov@yandex-team.ru \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).