public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Min-Hsun Chang <chmh0624@gmail.com>,
	arnd@arndb.de, msalter@redhat.com, linux-arch@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr)
Date: Sun, 26 Apr 2026 11:49:38 +0100	[thread overview]
Message-ID: <20260426114938.4dff28c8@pumpkin> (raw)
In-Reply-To: <20260425151240.2a46e3a8640fde3902461d41@linux-foundation.org>

On Sat, 25 Apr 2026 15:12:40 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sat, 25 Apr 2026 23:01:34 +0100 David Laight <david.laight.linux@gmail.com> wrote:
> 
> > > > The real problem with this define is that both idx and phys are
> > > > expanded twice.    
> > > 
> > > The real problem with this define is that it's a define.  Why oh why do
> > > we keep doing this to ourselves?  
> > 
> > Sometimes #defines generate better code because they are expanded earlier,
> > and sometimes you want type-agnostic 'functions'.
> > But neither is true here.
> > 
> > But I think I'd go for 'always_inline'.
> > Sometimes the compilers make silly decisions.  
> 
> Gee, if `static inline' misbehaves then we have big problems!
> 
> What's special about the fixmap code anyway?  It's not exactly
> fastpath.  Perhaps this stuff can simply be uninlined.

Some of the inlines are trivial - just adding an extra parameter.
But this set would be simpler if the last function
(__native_set_fixmap() for x86) returned (address & ~PAGE_MASK)

> 
> Pet peeves:
> 
> We use too many macros.

Indeed, I get fed up of looking things up to find they are trivial.
Some of the 'helpers' do nothing for core readability.
Even things like BIT() can have unexpected consequences.

Not to say I haven't got the pre-processor to do odd things in the past.
But it is usually trying to avoid having to keep multiple definitions
aligned with each other.

> We inline too much stuff.

True - don't look at what strlcpy() can generate.
The inline code should just get the constants from the compiler and
then call the appropriate function.

As does the compiler.
pixpaper_panel_hw_init() repeatedly calls two static functions that
contain sleeps. They all get inlined bloating the code size and
exploding the stack when clang separately allocates all the buffers
in the called functions.

	David



  reply	other threads:[~2026-04-26 10:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07  9:21 [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr) Min-Hsun Chang
2026-03-22 13:20 ` Min-Hsun Chang
2026-03-22 14:40 ` David Laight
2026-03-23  6:02   ` [PATCH v2] asm-generic: convert __set_fixmap_offset() to static inline Min-Hsun Chang
2026-04-25 20:57   ` [PATCH] asm-generic: replace ________addr with __UNIQUE_ID(addr) Andrew Morton
2026-04-25 22:01     ` David Laight
2026-04-25 22:12       ` Andrew Morton
2026-04-26 10:49         ` David Laight [this message]
2026-04-26 11:09           ` Andrew Morton
2026-04-26 17:34             ` David Laight
2026-04-26 18:09               ` Andrew Morton
2026-04-26 21:43                 ` David Laight

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=20260426114938.4dff28c8@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=chmh0624@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=msalter@redhat.com \
    /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