linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, rppt@linux.ibm.com, osalvador@suse.de,
	willy@infradead.org, william.kucharski@oracle.com
Subject: Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
Date: Tue, 26 Mar 2019 15:31:45 +0100	[thread overview]
Message-ID: <20190326143145.GR28406@dhcp22.suse.cz> (raw)
In-Reply-To: <20190326141803.GX3659@MiWiFi-R3L-srv>

On Tue 26-03-19 22:18:03, Baoquan He wrote:
> On 03/26/19 at 03:03pm, Michal Hocko wrote:
> > On Tue 26-03-19 21:45:22, Baoquan He wrote:
> > > On 03/26/19 at 11:17am, Michal Hocko wrote:
> > > > On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > > > > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > > > > On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > > > > > > Reorder the allocation of usemap and memmap since usemap allocation
> > > > > > > is much simpler and easier. Otherwise hard work is done to make
> > > > > > > memmap ready, then have to rollback just because of usemap allocation
> > > > > > > failure.
> > > > > > 
> > > > > > Is this really worth it? I can see that !VMEMMAP is doing memmap size
> > > > > > allocation which would be 2MB aka costly allocation but we do not do
> > > > > > __GFP_RETRY_MAYFAIL so the allocator backs off early.
> > > > > 
> > > > > In !VMEMMAP case, it truly does simple allocation directly. surely
> > > > > usemap which size is 32 is smaller. So it doesn't matter that much who's
> > > > > ahead or who's behind. However, this benefit a little in VMEMMAP case.
> > > > 
> > > > How does it help there? The failure should be even much less probable
> > > > there because we simply fall back to a small 4kB pages and those
> > > > essentially never fail.
> > > 
> > > OK, I am fine to drop it. Or only put the section existence checking
> > > earlier to avoid unnecessary usemap/memmap allocation?
> > 
> > DO you have any data on how often that happens? Should basically never
> > happening, right?
> 
> Oh, you think about it in this aspect. Yes, it rarely happens.
> Always allocating firstly can increase efficiency. Then I will just drop
> it.

OK, let me try once more. Doing a check early is something that makes
sense in general. Another question is whether the check is needed at
all. So rather than fiddling with its placement I would go whether it is
actually failing at all. I suspect it doesn't because the memory hotplug
is currently enforced to be section aligned. There are people who would
like to allow subsection or section unaligned aware hotplug and then
this would be much more relevant but without any solid justification
such a patch is not really helpful because it might cause code conflicts
with other work or obscure the git blame tracking by an additional hop.

In short, if you want to optimize something then make sure you describe
what you are optimizing how it helps.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2019-03-26 14:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-26  9:02 [PATCH v2 0/4] Clean up comments and codes in sparse_add_one_section() Baoquan He
2019-03-26  9:02 ` [PATCH v2 1/4] mm/sparse: Clean up the obsolete code comment Baoquan He
2019-03-26  9:23   ` Mike Rapoport
2019-03-26  9:23   ` Michal Hocko
2019-03-26  9:30     ` Baoquan He
2019-03-26  9:36       ` Chao Fan
2019-03-26  9:43         ` Baoquan He
2019-03-26  9:46           ` Chao Fan
2019-03-26  9:02 ` [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section() Baoquan He
2019-03-26  9:23   ` Mike Rapoport
2019-03-26  9:29   ` Michal Hocko
2019-03-26 10:08     ` Baoquan He
2019-03-26 10:17       ` Michal Hocko
2019-03-26 13:45         ` Baoquan He
2019-03-26 13:57           ` Mike Rapoport
2019-03-26 14:03           ` Michal Hocko
2019-03-26 14:18             ` Baoquan He
2019-03-26 14:31               ` Michal Hocko [this message]
2019-03-26 22:57                 ` Baoquan He
2019-03-26  9:02 ` [PATCH v2 3/4] mm/sparse: Rename function related to section memmap allocation/free Baoquan He
2019-03-26  9:02 ` [PATCH v2 4/4] drivers/base/memory.c: Rename the misleading parameter Baoquan He
2019-03-26  9:20   ` Rafael J. Wysocki
2019-03-26  9:33   ` Michal Hocko
2019-03-26 11:43   ` Matthew Wilcox
2019-03-26 12:42     ` Baoquan He
2019-03-29  6:44 ` [PATCH v2 0/4] Clean up comments and codes in sparse_add_one_section() Baoquan He

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=20190326143145.GR28406@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=rppt@linux.ibm.com \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.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