All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: carver4lio@163.com
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Hailong Liu <liu.hailong6@zte.com.cn>
Subject: Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages
Date: Sun, 6 Dec 2020 13:55:17 +0200	[thread overview]
Message-ID: <20201206115517.GL751215@kernel.org> (raw)
In-Reply-To: <20201203152311.5272-1-carver4lio@163.com>

On Thu, Dec 03, 2020 at 11:23:10PM +0800, carver4lio@163.com wrote:
> From: Hailong Liu <liu.hailong6@zte.com.cn>
> 
> When system in the booting stage, pages span from [start, end] of a memblock
> are freed to buddy in a order as large as possible (less than MAX_ORDER) at
> first, then decrease gradually to a proper order(less than end) in a loop.
> 
> However, *min(MAX_ORDER - 1UL, __ffs(start))* can not get the largest order
> in some cases.

Do you have examples?
What is the memory configration that casues suboptimal order selection
and what is the order in this case?

> Instead, *__ffs(end - start)* may be more appropriate and meaningful.

As several people reported using __ffs(end - start) is not correct.
If the order selection is indeed suboptimal we'd need some better
formula ;-)

> Signed-off-by: Hailong Liu <liu.hailong6@zte.com.cn>
> ---
>  mm/memblock.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index b68ee8678..7c6d0dde7 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1931,7 +1931,7 @@ static void __init __free_pages_memory(unsigned long start, unsigned long end)
>  	int order;
>  
>  	while (start < end) {
> -		order = min(MAX_ORDER - 1UL, __ffs(start));
> +		order = min(MAX_ORDER - 1UL, __ffs(end - start));
>  
>  		while (start + (1UL << order) > end)
>  			order--;
> -- 
> 2.17.1
> 
> 

-- 
Sincerely yours,
Mike.


  parent reply	other threads:[~2020-12-06 11:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 15:23 [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages carver4lio
2020-12-04 13:42 ` Qian Cai
2020-12-04 16:07   ` Marek Szyprowski
2020-12-04 17:43     ` Jon Hunter
2020-12-05 17:09       ` Anders Roxell
2020-12-05 17:12         ` Anders Roxell
2020-12-06 11:55 ` Mike Rapoport [this message]
2020-12-06 14:21   ` carver4lio

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=20201206115517.GL751215@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=carver4lio@163.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liu.hailong6@zte.com.cn \
    /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.