From: Peter Zijlstra <peterz@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
akpm@linux-foundation.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function
Date: Thu, 22 Oct 2015 17:09:59 +0200 [thread overview]
Message-ID: <20151022150959.GU17308@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <57854232.vMTrn4EgZx@wuerfel>
On Thu, Oct 22, 2015 at 05:02:45PM +0200, Arnd Bergmann wrote:
> On Tuesday 13 October 2015 23:46:35 Arnd Bergmann wrote:
> > On Tuesday 13 October 2015 22:38:12 Peter Zijlstra wrote:
> > > A quick grep shows a large amount of trivial code that optimizers will
> > > still happily throw away, but it should be verified that this does not
> > > result in pointless code generation.
> >
> > Indeed, I'm seeing a tiny code growth with ARM multi_v7_defconfig when
> > my patch is applied, as the image (according to size -A) grows from
> > 13740187 bytes to 13740283, all of it in .text of two drivers (i2c-core
> > and three files of bluetooth.ko).
>
>
> Did we actually reach any conclusion here? We still get the warnings
> in the regulator code in linux-next, and I'd like to see either this
> patch ("mutex: make mutex_lock_nested an inline function") or
> "regulator: core: avoid unused variable warning" get merged.
>
> We could also remove the two functions again, as they are still
> unused and we are getting closer to the merge window.
Hmm, I was sure I send a reply, but I cannot even find it in my own sent
folder so who knows.
My current preference is to keep the thing a macro and work around it in
the usage site because while these warns are annoying, they're at least
visible. Whereas, with an inline, code bloat is entirely silent. Even if
the sites you found are harmless, there's no saying what the future will
bring etc..
next prev parent reply other threads:[~2015-10-22 15:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 20:30 Arnd Bergmann
2015-10-13 20:38 ` Peter Zijlstra
2015-10-13 21:46 ` Arnd Bergmann
2015-10-14 8:20 ` Peter Zijlstra
2015-10-14 8:37 ` Peter Zijlstra
2015-10-14 9:00 ` Arnd Bergmann
2015-10-14 9:08 ` Peter Zijlstra
2015-10-14 9:59 ` Mark Brown
2015-10-14 10:27 ` Mark Brown
2015-10-14 11:07 ` Peter Zijlstra
2015-10-14 12:36 ` Mark Brown
2015-10-14 13:47 ` Peter Zijlstra
2015-10-14 13:50 ` Peter Zijlstra
2015-10-14 13:58 ` Ingo Molnar
2015-10-14 14:11 ` Mark Brown
2015-10-22 15:02 ` Arnd Bergmann
2015-10-22 15:09 ` Peter Zijlstra [this message]
2015-10-22 17:44 ` Russell King - ARM Linux
2015-10-27 18:13 ` Ingo Molnar
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=20151022150959.GU17308@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome