From: Michal Hocko <mhocko@kernel.org>
To: Arun KS <arunks@codeaurora.org>
Cc: 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 v6 1/2] memory_hotplug: Free pages as higher order
Date: Tue, 6 Nov 2018 21:08:23 +0100 [thread overview]
Message-ID: <20181106200823.GT27423@dhcp22.suse.cz> (raw)
In-Reply-To: <542cd3516b54d88d1bffede02c6045b8@codeaurora.org>
On Tue 06-11-18 21:01:29, Arun KS wrote:
> On 2018-11-06 19:36, Michal Hocko wrote:
> > On Tue 06-11-18 11:33:13, Arun KS wrote:
> > > When free pages are done with higher order, time spend 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%. Modify external
> > > providers of online callback to align with the change.
> > >
> > > This patch modifies totalram_pages, zone->managed_pages and
> > > totalhigh_pages outside managed_page_count_lock. A follow up
> > > series will be send to convert these variable to atomic to
> > > avoid readers potentially seeing a store tear.
> >
> > Is there any reason to rush this through rather than wait for counters
> > conversion first?
>
> Sure Michal.
>
> Conversion patch, https://patchwork.kernel.org/cover/10657217/ is currently
> incremental to this patch.
The ordering should be other way around. Because as things stand with
this patch first it is possible to introduce a subtle race prone
updates. As I've said I am skeptical the race would matter, really, but
there is no real reason to risk for that. Especially when you have the
other (first) half ready.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-11-06 20:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-06 6:03 [PATCH v6 1/2] memory_hotplug: Free pages as higher order Arun KS
2018-11-06 6:03 ` [PATCH v6 2/2] mm/page_alloc: remove software prefetching in __free_pages_core Arun KS
2018-11-06 14:08 ` Michal Hocko
2018-11-06 14:06 ` [PATCH v6 1/2] memory_hotplug: Free pages as higher order Michal Hocko
2018-11-06 15:31 ` Arun KS
2018-11-06 20:08 ` Michal Hocko [this message]
2018-11-07 6:21 ` Arun KS
2019-01-04 5:05 ` Arun KS
2019-01-04 8:58 ` Michal Hocko
2019-01-04 9:01 ` Arun Sudhilal
2019-01-04 9:01 ` Arun Sudhilal
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=20181106200823.GT27423@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--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 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.