All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Yajun Deng <yajun.deng@linux.dev>
Cc: David Hildenbrand <david@redhat.com>,
	akpm@linux-foundation.org, mike.kravetz@oracle.com,
	muchun.song@linux.dev, willy@infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] mm: Init page count in reserve_bootmem_region when MEMINIT_EARLY
Date: Mon, 16 Oct 2023 09:33:57 +0300	[thread overview]
Message-ID: <20231016063357.GU3303@kernel.org> (raw)
In-Reply-To: <1c91dd62-886d-bb05-8aee-22191a8a2d8e@linux.dev>

On Fri, Oct 13, 2023 at 05:29:19PM +0800, Yajun Deng wrote:
> 
> On 2023/10/13 16:48, Mike Rapoport wrote:
> > On Thu, Oct 12, 2023 at 05:53:22PM +0800, Yajun Deng wrote:
> > > On 2023/10/12 17:23, David Hildenbrand wrote:
> > > > On 10.10.23 04:31, Yajun Deng wrote:
> > > > > On 2023/10/8 16:57, Yajun Deng wrote:
> > > > > > > That looks wrong. if the page count would by pure luck be 0
> > > > > > > already for hotplugged memory, you wouldn't clear the reserved
> > > > > > > flag.
> > > > > > > 
> > > > > > > These changes make me a bit nervous.
> > > > > > Is 'if (page_count(page) || PageReserved(page))' be safer? Or do I
> > > > > > need to do something else?
> > > > > > 
> > > > > How about the following if statement? But it needs to add more patch
> > > > > like v1 ([PATCH 2/4] mm: Introduce MEMINIT_LATE context).
> > > > > 
> > > > > It'll be safer, but more complex. Please comment...
> > > > > 
> > > > >      if (context != MEMINIT_EARLY || (page_count(page) ||
> > > > > PageReserved(page)) {
> > > > > 
> > > > Ideally we could make initialization only depend on the context, and not
> > > > check for count or the reserved flag.
> > > > 
> > > This link is v1,
> > > https://lore.kernel.org/all/20230922070923.355656-1-yajun.deng@linux.dev/
> > > 
> > > If we could make initialization only depend on the context, I'll modify it
> > > based on v1.
> > Although ~20% improvement looks impressive, this is only optimization of a
> > fraction of the boot time, and realistically, how much 56 msec saves from
> > the total boot time when you boot a machine with 190G of RAM?
> 
> There are a lot of factors that can affect the total boot time. 56 msec
> saves may be insignificant.
> 
> But if we look at the boot log, we'll see there's a significant time jump.
> 
> before:
> 
> [    0.250334] ACPI: PM-Timer IO Port: 0x508
> [    0.618994] Memory: 173413056K/199884452K available (18440K kernel code,
> 
> after:
> 
> [    0.260229] software IO TLB: area num 32.
> [    0.563497] Memory: 173413056K/199884452K available (18440K kernel code,
> 
> Memory initialization is time consuming in the boot log.

You just confirmed that 56 msec is insignificant and then you send again
the improvement of ~60 msec in memory initialization.

What does this improvement gain in percentage of total boot time?
 
> > I still think the improvement does not justify the churn, added complexity
> > and special casing of different code paths of initialization of struct pages.
> 
> 
> Because there is a loop, if the order is MAX_ORDER, the loop will run 1024
> times. The following 'if' would be safer:
> 
> 'if (context != MEMINIT_EARLY || (page_count(page) || >> PageReserved(page))
> {'

No, it will not.

As the matter of fact any condition here won't be 'safer' because it makes
the code more complex and less maintainable. 
Any future change in __free_pages_core() or one of it's callers will have
to reason what will happen with that condition after the change.

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2023-10-16  6:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-28  8:33 [PATCH v4 0/2] mm: Don't set and reset page count in MEMINIT_EARLY Yajun Deng
2023-09-28  8:33 ` [PATCH v4 1/2] mm: pass page count and reserved to __init_single_page Yajun Deng
2023-09-29  8:19   ` Mike Rapoport
2023-09-29  9:37     ` Yajun Deng
2023-09-28  8:33 ` [PATCH v4 2/2] mm: Init page count in reserve_bootmem_region when MEMINIT_EARLY Yajun Deng
2023-09-29  8:30   ` Mike Rapoport
2023-09-29  9:50     ` Yajun Deng
2023-09-29 10:02       ` Mike Rapoport
2023-09-29 10:27         ` Yajun Deng
2023-10-01 18:59           ` Mike Rapoport
2023-10-02  7:03             ` Yajun Deng
2023-10-02  8:47               ` Mike Rapoport
2023-10-02  8:56                 ` David Hildenbrand
2023-10-02 11:10                   ` Mike Rapoport
2023-10-02 11:25                     ` David Hildenbrand
2023-10-03 14:38                       ` Yajun Deng
2023-10-05  5:06                         ` Mike Rapoport
2023-10-05 14:04                           ` Yajun Deng
2023-10-12  9:19                             ` Mike Rapoport
2023-10-12  9:36                               ` Yajun Deng
2023-10-02  8:30     ` David Hildenbrand
2023-10-08  8:57       ` Yajun Deng
2023-10-10  2:31         ` Yajun Deng
2023-10-12  9:23           ` David Hildenbrand
2023-10-12  9:53             ` Yajun Deng
2023-10-13  8:48               ` Mike Rapoport
2023-10-13  9:29                 ` Yajun Deng
2023-10-16  6:33                   ` Mike Rapoport [this message]
2023-10-16  8:10                     ` Yajun Deng
2023-10-16  8:16                       ` David Hildenbrand
2023-10-16  8:32                         ` Yajun Deng
2023-10-16  8:36                           ` David Hildenbrand
2023-10-16 10:17                             ` Yajun Deng
2023-10-17  9:58                               ` Yajun Deng

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=20231016063357.GU3303@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=willy@infradead.org \
    --cc=yajun.deng@linux.dev \
    /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.