From: Michal Hocko <mhocko@kernel.org>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Arun KS <arunks@codeaurora.org>,
arunks.linux@gmail.com, akpm@linux-foundation.org,
vbabka@suse.cz, osalvador@suse.de, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, getarunks@gmail.com
Subject: Re: [PATCH v7] mm/page_alloc.c: memory_hotplug: free pages as higher order
Date: Tue, 8 Jan 2019 21:04:36 +0100 [thread overview]
Message-ID: <20190108200436.GK31793@dhcp22.suse.cz> (raw)
In-Reply-To: <37498672d5b2345b1435477e78251282af42742b.camel@linux.intel.com>
On Tue 08-01-19 10:40:18, Alexander Duyck wrote:
> On Fri, 2019-01-04 at 10:31 +0530, Arun KS wrote:
> > When freeing pages are done with higher order, time spent on coalescing
> > pages by buddy allocator can be reduced. With section size of 256MB, hot
> > add latency of a single section shows improvement from 50-60 ms to less
> > than 1 ms, hence improving the hot add latency by 60 times. Modify
> > external providers of online callback to align with the change.
> >
> > Signed-off-by: Arun KS <arunks@codeaurora.org>
> > Acked-by: Michal Hocko <mhocko@suse.com>
> > Reviewed-by: Oscar Salvador <osalvador@suse.de>
>
> After running into my initial issue I actually had a few more questions
> about this patch.
>
> > [...]
> > +static int online_pages_blocks(unsigned long start, unsigned long nr_pages)
> > +{
> > + unsigned long end = start + nr_pages;
> > + int order, ret, onlined_pages = 0;
> > +
> > + while (start < end) {
> > + order = min(MAX_ORDER - 1,
> > + get_order(PFN_PHYS(end) - PFN_PHYS(start)));
> > +
> > + ret = (*online_page_callback)(pfn_to_page(start), order);
> > + if (!ret)
> > + onlined_pages += (1UL << order);
> > + else if (ret > 0)
> > + onlined_pages += ret;
> > +
> > + start += (1UL << order);
> > + }
> > + return onlined_pages;
> > }
> >
>
> Should the limit for this really be MAX_ORDER - 1 or should it be
> pageblock_order? In some cases this will be the same value, but I seem
> to recall that for x86 MAX_ORDER can be several times larger than
> pageblock_order.
Does it make any difference when we are in fact trying to onine nr_pages
and we clamp to it properly?
> > static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
> > void *arg)
> > {
> > - unsigned long i;
> > unsigned long onlined_pages = *(unsigned long *)arg;
> > - struct page *page;
> >
> > if (PageReserved(pfn_to_page(start_pfn)))
>
> I'm not sure we even really need this check. Getting back to the
> discussion I have been having with Michal in regards to the need for
> the DAX pages to not have the reserved bit cleared I was originally
> wondering if we could replace this check with a call to
> online_section_nr since the section shouldn't be online until we set
> the bit below in online_mem_sections.
>
> However after doing some further digging it looks like this could
> probably be dropped entirely since we only call this function from
> online_pages and that function is only called by memory_block_action if
> pages_correctly_probed returns true. However pages_correctly_probed
> should return false if any of the sections contained in the page range
> is already online.
Yes you are right but I guess it would be better to address in a
separate patch that deals with PageReserved manipulation in general.
I do not think we want to remove the check silently. People who might be
interested in backporting this for whatever reason might screatch their
head why the test is not needed anymore.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-01-08 20:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 5:01 Arun KS
2019-01-08 17:56 ` Alexander Duyck
2019-01-08 17:56 ` Alexander Duyck
2019-01-08 18:13 ` Michal Hocko
2019-01-09 5:58 ` Arun KS
2019-01-09 7:37 ` Michal Hocko
2019-01-09 8:28 ` Arun KS
2019-01-09 8:40 ` Michal Hocko
2019-01-09 10:42 ` Arun KS
2019-01-09 10:57 ` Michal Hocko
2019-01-09 11:06 ` Arun KS
2019-01-09 18:56 ` Andrew Morton
2019-01-10 5:06 ` Arun KS
2019-01-08 18:40 ` Alexander Duyck
2019-01-08 18:40 ` Alexander Duyck
2019-01-08 20:04 ` Michal Hocko [this message]
2019-01-08 21:53 ` Alexander Duyck
2019-01-08 21:53 ` Alexander Duyck
2019-01-08 22:17 ` Alexander Duyck
2019-01-08 22:17 ` Alexander Duyck
2019-01-09 6:21 ` Arun KS
2019-01-09 16:09 ` Alexander Duyck
2019-01-09 16:09 ` Alexander Duyck
2019-01-10 4:39 ` Arun KS
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=20190108200436.GK31793@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=arunks.linux@gmail.com \
--cc=arunks@codeaurora.org \
--cc=getarunks@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--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