From: Matthew Wilcox <willy@infradead.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>,
Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Dan Williams <dan.j.williams@intel.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
David Hildenbrand <david@redhat.com>,
Jason Wang <jasowang@redhat.com>, Michal Hocko <mhocko@suse.com>,
Liang Li <liliangleo@didiglobal.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO
Date: Mon, 4 Jan 2021 19:27:53 +0000 [thread overview]
Message-ID: <20210104192753.GD22407@casper.infradead.org> (raw)
In-Reply-To: <0e8b6a2f-527d-7c77-efcf-04f21ef2a77c@intel.com>
On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote:
> On 12/21/20 8:30 AM, Liang Li wrote:
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -137,6 +137,9 @@ enum pageflags {
> > #endif
> > #ifdef CONFIG_64BIT
> > PG_arch_2,
> > +#endif
> > +#ifdef CONFIG_PREZERO_PAGE
> > + PG_zero,
> > #endif
> > __NR_PAGEFLAGS,
>
> I don't think this is worth a generic page->flags bit.
>
> There's a ton of space in 'struct page' for pages that are in the
> allocator. Can't we use some of that space?
I was going to object to that too, but I think the entire approach is
flawed and needs to be thrown out. It just nukes the caches in extremely
subtle and hard to measure ways, lowering overall system performance.
next prev parent reply other threads:[~2021-01-04 19:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-21 16:30 Liang Li
2021-01-04 19:19 ` Dave Hansen
2021-01-04 19:27 ` Matthew Wilcox [this message]
2021-01-04 19:44 ` Dan Williams
2021-01-04 19:51 ` Dave Hansen
2021-01-04 20:11 ` David Hildenbrand
2021-01-04 22:29 ` Dan Williams
2021-01-04 23:00 ` Dave Hansen
2021-01-05 9:20 ` Michal Hocko
2021-01-05 9:29 ` David Hildenbrand
2021-01-05 9:39 ` Liang Li
2021-01-05 9:56 ` Michal Hocko
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=20210104192753.GD22407@casper.infradead.org \
--to=willy@infradead.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=jasowang@redhat.com \
--cc=liliangleo@didiglobal.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.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