All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: vbabka@suse.cz, sfr@canb.auug.org.au, peterz@infradead.org,
	mgorman@techsingularity.net, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/6] mm/page_alloc.c: simplify the code by using macro K()
Date: Wed, 01 Sep 2021 09:46:17 +0200	[thread overview]
Message-ID: <5931202.uRb02ylMo7@natalenko.name> (raw)
In-Reply-To: <03653d41-abe0-46f0-9eee-28cad9f5edea@huawei.com>

Hello.

On středa 1. září 2021 9:37:49 CEST Miaohe Lin wrote:
> On 2021/8/31 22:19, Oleksandr Natalenko wrote:
> > On úterý 31. srpna 2021 13:08:42 CEST Miaohe Lin wrote:
> >> On 2021/8/31 16:54, Oleksandr Natalenko wrote:
> >>> On pondělí 30. srpna 2021 16:10:47 CEST Miaohe Lin wrote:
> >>>> Use helper macro K() to convert the pages to the corresponding size.
> >>>> Minor readability improvement.
> >>>> 
> >>>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> >>>> ---
> >>>> 
> >>>>  mm/page_alloc.c | 12 +++++-------
> >>>>  1 file changed, 5 insertions(+), 7 deletions(-)
> >>>> 
> >>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>>> index dbb3338d9287..d3983244f56f 100644
> >>>> --- a/mm/page_alloc.c
> >>>> +++ b/mm/page_alloc.c
> >>>> @@ -8134,8 +8134,7 @@ unsigned long free_reserved_area(void *start,
> >>>> void
> >>>> *end, int poison, const char }
> >>>> 
> >>>>  	if (pages && s)
> >>>> 
> >>>> -		pr_info("Freeing %s memory: %ldK\n",
> >>>> -			s, pages << (PAGE_SHIFT - 10));
> >>>> +		pr_info("Freeing %s memory: %ldK\n", s, K(pages));
> >>>> 
> >>>>  	return pages;
> >>>>  
> >>>>  }
> >>>> 
> >>>> @@ -8180,14 +8179,13 @@ void __init mem_init_print_info(void)
> >>>> 
> >>>>  		", %luK highmem"
> >>>>  
> >>>>  #endif
> >>>>  
> >>>>  		")\n",
> >>>> 
> >>>> -		nr_free_pages() << (PAGE_SHIFT - 10),
> >>>> -		physpages << (PAGE_SHIFT - 10),
> >>>> +		K(nr_free_pages()), K(physpages),
> >>>> 
> >>>>  		codesize >> 10, datasize >> 10, rosize >> 10,
> >>>>  		(init_data_size + init_code_size) >> 10, bss_size >> 10,
> >>>> 
> >>>> -		(physpages - totalram_pages() - totalcma_pages) << 
(PAGE_SHIFT
> >>> 
> >>> - 10),
> >>> 
> >>>> -		totalcma_pages << (PAGE_SHIFT - 10)
> >>>> +		K(physpages - totalram_pages() - totalcma_pages),
> >>>> +		K(totalcma_pages)
> >>>> 
> >>>>  #ifdef	CONFIG_HIGHMEM
> >>>> 
> >>>> -		, totalhigh_pages() << (PAGE_SHIFT - 10)
> >>>> +		, K(totalhigh_pages())
> >>>> 
> >>>>  #endif
> >>>>  
> >>>>  		);
> >>>>  
> >>>>  }
> >>> 
> >>> (my concern is not quite within the scope of this submission, but I'll
> >>> ask
> >>> anyway)
> >>> 
> >>> Given we have this:
> >>> 
> >>> ```
> >>> git grep '#define K(x)' v5.14
> >>> v5.14:drivers/base/node.c:#define K(x) ((x) << (PAGE_SHIFT - 10))
> >>> v5.14:drivers/net/hamradio/scc.c:#define K(x) kiss->x
> >>> v5.14:kernel/debug/kdb/kdb_main.c:#define K(x) ((x) << (PAGE_SHIFT -
> >>> 10))
> >>> v5.14:mm/backing-dev.c:#define K(x) ((x) << (PAGE_SHIFT - 10))
> >>> v5.14:mm/memcontrol.c:#define K(x) ((x) << (PAGE_SHIFT-10))
> >>> v5.14:mm/oom_kill.c:#define K(x) ((x) << (PAGE_SHIFT-10))
> >>> v5.14:mm/page_alloc.c:#define K(x) ((x) << (PAGE_SHIFT-10))
> >>> ```
> >>> 
> >>> Shouldn't this macro go to some header file instead to get rid of define
> >>> repetitions?
> >> 
> >> Many thanks for figuring this out. I think we should get rid of these
> >> repetitions too. But I'am not sure where this definition should be. Any
> >> suggestion? Thanks.
> > 
> > I'm not sure what place suits best. At first I thought maybe linux/mm.h or
> > linux/mm_inline.h, but since PAGE_SHIFT is declared in asm-generic/page.h,
> > probably K(x) can also go there as well?
> 
> K(x) is relevant with PAGE_SHIFT. So I think K(x) can also go
> asm-generic/page.h too.

Actually, the comment in this file says:

```
4 /*
5  * Generic page.h implementation, for NOMMU architectures.
6  * This provides the dummy definitions for the memory management.
7  */
```

so it seems I was wrong about this being an appropriate place.

> Am I supposed to do this when free or will you
> kindly do this?

Let me just try to cram this into mm.h and send it out, and then we'll see 
what comments people suggest.

Thanks.

-- 
Oleksandr Natalenko (post-factum)



  reply	other threads:[~2021-09-01  7:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30 14:10 [PATCH 0/6] Cleanups and fixup for page_alloc Miaohe Lin
2021-08-30 14:10 ` [PATCH 1/6] mm/page_alloc.c: remove meaningless VM_BUG_ON() in pindex_to_order() Miaohe Lin
2021-08-31 13:34   ` Mel Gorman
2021-08-31 14:05   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 2/6] mm/page_alloc.c: simplify the code by using macro K() Miaohe Lin
2021-08-31  8:54   ` Oleksandr Natalenko
2021-08-31 11:08     ` Miaohe Lin
2021-08-31 14:19       ` Oleksandr Natalenko
2021-09-01  7:37         ` Miaohe Lin
2021-09-01  7:46           ` Oleksandr Natalenko [this message]
2021-09-01  8:17             ` Miaohe Lin
2021-09-01 21:25           ` David Laight
2021-09-02  6:32             ` Miaohe Lin
2021-08-31 13:35   ` Mel Gorman
2021-08-31 14:07   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 3/6] mm/page_alloc.c: remove obsolete comment in free_pcppages_bulk() Miaohe Lin
2021-08-31 13:38   ` Mel Gorman
2021-09-01  7:49     ` Miaohe Lin
2021-09-01 15:14       ` Mel Gorman
2021-09-02  6:25         ` Miaohe Lin
2021-08-30 14:10 ` [PATCH 4/6] mm/page_alloc.c: use helper function zone_spans_pfn() Miaohe Lin
2021-08-31 13:39   ` Mel Gorman
2021-08-31 14:08   ` David Hildenbrand
2021-08-30 14:10 ` [PATCH 5/6] mm/page_alloc.c: avoid accessing uninitialized pcp page migratetype Miaohe Lin
2021-08-31 13:43   ` Mel Gorman
2021-08-31 14:23     ` David Hildenbrand
2021-09-01  8:02       ` Miaohe Lin
2021-09-01  8:10         ` David Hildenbrand
2021-09-01  8:18           ` Miaohe Lin
2021-08-31 16:34     ` Vlastimil Babka
2021-09-01  8:04       ` Miaohe Lin
2021-08-30 14:10 ` [PATCH 6/6] mm/page_alloc.c: avoid allocating highmem pages via alloc_pages_exact_nid() Miaohe Lin
2021-08-30 14:24   ` Matthew Wilcox
2021-08-31  1:56     ` Miaohe Lin
2021-08-31 16:37       ` Vlastimil Babka
2021-09-01  8:05         ` Miaohe Lin

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=5931202.uRb02ylMo7@natalenko.name \
    --to=oleksandr@natalenko.name \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=peterz@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --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.