All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] mm/mm_init.c: remove meaningless calculation of zone->managed_pages in free_area_init_core()
Date: Wed, 20 Mar 2024 16:18:18 +0800	[thread overview]
Message-ID: <ZfqbygfNmFKpBCfR@MiWiFi-R3L-srv> (raw)
In-Reply-To: <Zfm6gzhKUehLwM5-@kernel.org>

On 03/19/24 at 06:17pm, Mike Rapoport wrote:
> On Mon, Mar 18, 2024 at 10:21:36PM +0800, Baoquan He wrote:
> > Currently, in free_area_init_core(), when initialize zone's field, a
> > rough value is set to zone->managed_pages. That value is calculated by
> > (zone->present_pages - memmap_pages).
> > 
> > In the meantime, add the value to nr_all_pages and nr_kernel_pages which
> > represent all free pages of system (only low memory or including HIGHMEM
> > memory separately). Both of them are gonna be used in
> > alloc_large_system_hash().
> > 
> > However, the rough calculation and setting of zone->managed_pages is
> > meaningless because
> >   a) memmap pages are allocated on units of node in sparse_init() or
> >      alloc_node_mem_map(pgdat); The simple (zone->present_pages -
> >      memmap_pages) is too rough to make sense for zone;
> >   b) the set zone->managed_pages will be zeroed out and reset with
> >      acutal value in mem_init() via memblock_free_all(). Before the
> >      resetting, no buddy allocation request is issued.
> > 
> > Here, remove the meaningless and complicated calculation of
> > (zone->present_pages - memmap_pages), directly set zone->present_pages to
> > zone->managed_pages. It will be adjusted in mem_init().
> 
> Do you mean "set zone->managed_pages to zone->present_pages"?

Hmm, maybe 'set zone->managed_pages as zone->present_pages'
            or 
           'assign zone->present_pages to zone->managed_pages'
which is more precise.

Wwill update.

> 
> I think we can just set zone->managed_pages to 0 in free_area_init_core().
> Anyway it will be reset before the first use.

Yeah, setting to 0 is also fine. I thougt of 0 ever. Considering
zone->present_pages is closer value to actual zone->managed_pages
than 0, and it may be needed in the future in some way before
mem_init(). If no strong objection, I will keep the assigning
'zone->present_pages' to 'zone->managed_pages'.

Thanks again for careful reviewing.


WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org,
	linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org
Subject: Re: [PATCH 4/6] mm/mm_init.c: remove meaningless calculation of zone->managed_pages in free_area_init_core()
Date: Wed, 20 Mar 2024 16:18:18 +0800	[thread overview]
Message-ID: <ZfqbygfNmFKpBCfR@MiWiFi-R3L-srv> (raw)
In-Reply-To: <Zfm6gzhKUehLwM5-@kernel.org>

On 03/19/24 at 06:17pm, Mike Rapoport wrote:
> On Mon, Mar 18, 2024 at 10:21:36PM +0800, Baoquan He wrote:
> > Currently, in free_area_init_core(), when initialize zone's field, a
> > rough value is set to zone->managed_pages. That value is calculated by
> > (zone->present_pages - memmap_pages).
> > 
> > In the meantime, add the value to nr_all_pages and nr_kernel_pages which
> > represent all free pages of system (only low memory or including HIGHMEM
> > memory separately). Both of them are gonna be used in
> > alloc_large_system_hash().
> > 
> > However, the rough calculation and setting of zone->managed_pages is
> > meaningless because
> >   a) memmap pages are allocated on units of node in sparse_init() or
> >      alloc_node_mem_map(pgdat); The simple (zone->present_pages -
> >      memmap_pages) is too rough to make sense for zone;
> >   b) the set zone->managed_pages will be zeroed out and reset with
> >      acutal value in mem_init() via memblock_free_all(). Before the
> >      resetting, no buddy allocation request is issued.
> > 
> > Here, remove the meaningless and complicated calculation of
> > (zone->present_pages - memmap_pages), directly set zone->present_pages to
> > zone->managed_pages. It will be adjusted in mem_init().
> 
> Do you mean "set zone->managed_pages to zone->present_pages"?

Hmm, maybe 'set zone->managed_pages as zone->present_pages'
            or 
           'assign zone->present_pages to zone->managed_pages'
which is more precise.

Wwill update.

> 
> I think we can just set zone->managed_pages to 0 in free_area_init_core().
> Anyway it will be reset before the first use.

Yeah, setting to 0 is also fine. I thougt of 0 ever. Considering
zone->present_pages is closer value to actual zone->managed_pages
than 0, and it may be needed in the future in some way before
mem_init(). If no strong objection, I will keep the assigning
'zone->present_pages' to 'zone->managed_pages'.

Thanks again for careful reviewing.



  reply	other threads:[~2024-03-20  8:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 14:21 [PATCH 0/6] mm/mm_init.c: refactor free_area_init_core() Baoquan He
2024-03-18 14:21 ` Baoquan He
2024-03-18 14:21 ` [PATCH 1/6] mm/mm_init.c: remove the useless dma_reserve Baoquan He
2024-03-18 14:21   ` Baoquan He
2024-03-18 14:21 ` [PATCH 2/6] x86: remove memblock_find_dma_reserve() Baoquan He
2024-03-18 14:21   ` Baoquan He
2024-03-19 15:49   ` Mike Rapoport
2024-03-19 15:49     ` Mike Rapoport
2024-03-20  7:52     ` Baoquan He
2024-03-20  7:52       ` Baoquan He
2024-03-20  9:36       ` Mike Rapoport
2024-03-20  9:36         ` Mike Rapoport
2024-03-20 13:14         ` Baoquan He
2024-03-20 13:14           ` Baoquan He
2024-03-18 14:21 ` [PATCH 3/6] mm/mm_init.c: add new function calc_nr_kernel_pages() Baoquan He
2024-03-18 14:21   ` Baoquan He
2024-03-18 14:21 ` [PATCH 4/6] mm/mm_init.c: remove meaningless calculation of zone->managed_pages in free_area_init_core() Baoquan He
2024-03-18 14:21   ` Baoquan He
2024-03-19 16:17   ` Mike Rapoport
2024-03-19 16:17     ` Mike Rapoport
2024-03-20  8:18     ` Baoquan He [this message]
2024-03-20  8:18       ` Baoquan He
2024-03-20  8:47       ` Baoquan He
2024-03-20  8:47         ` Baoquan He
2024-03-18 14:21 ` [PATCH 5/6] mm/mm_init.c: remove unneeded calc_memmap_size() Baoquan He
2024-03-18 14:21   ` Baoquan He
2024-03-18 14:21 ` [PATCH 6/6] mm/mm_init.c: remove arch_reserved_kernel_pages() Baoquan He
2024-03-18 14:21   ` 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=ZfqbygfNmFKpBCfR@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=rppt@kernel.org \
    --cc=x86@kernel.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 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.