From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mutex: make mutex_lock_nested an inline function
Date: Tue, 27 Oct 2015 19:13:51 +0100 [thread overview]
Message-ID: <20151027181351.GA15015@gmail.com> (raw)
In-Reply-To: <20151022174400.GW32532@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Oct 22, 2015 at 05:09:59PM +0200, Peter Zijlstra wrote:
> > 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..
>
> I agree - we've got way too many inline functions already. My biggest annoyance
> in that respect is the asm-generic dma_map_single() implementation that we're
> now forced to use on ARM, which results in quite a large chunk of code at every
> callsite.
>
> The problem there is that when you have drivers which do something like:
>
> dma = dma_map_single(dev, page_address(page), size, dir);
>
> you end up with code which converts the struct page to a virtual address, and
> then you end up with code in the dma_map_single() inline function which then
> converts it back to a struct page + offset - none of which, with modern ARM
> kernels, the compiler has a hope in hell of optimising.
>
> So we end up with all that junk at every single dma_map_single() callsite. If
> dma_map_single() were a library function, it would be a lot smaller since we'd
> only have one copy of the complex virt->struct page conversion.
Should be pretty easy to fix, once you know which inline functions hurt.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
akpm@linux-foundation.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function
Date: Tue, 27 Oct 2015 19:13:51 +0100 [thread overview]
Message-ID: <20151027181351.GA15015@gmail.com> (raw)
In-Reply-To: <20151022174400.GW32532@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Oct 22, 2015 at 05:09:59PM +0200, Peter Zijlstra wrote:
> > 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..
>
> I agree - we've got way too many inline functions already. My biggest annoyance
> in that respect is the asm-generic dma_map_single() implementation that we're
> now forced to use on ARM, which results in quite a large chunk of code at every
> callsite.
>
> The problem there is that when you have drivers which do something like:
>
> dma = dma_map_single(dev, page_address(page), size, dir);
>
> you end up with code which converts the struct page to a virtual address, and
> then you end up with code in the dma_map_single() inline function which then
> converts it back to a struct page + offset - none of which, with modern ARM
> kernels, the compiler has a hope in hell of optimising.
>
> So we end up with all that junk at every single dma_map_single() callsite. If
> dma_map_single() were a library function, it would be a lot smaller since we'd
> only have one copy of the complex virt->struct page conversion.
Should be pretty easy to fix, once you know which inline functions hurt.
Thanks,
Ingo
next prev parent reply other threads:[~2015-10-27 18:13 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 20:30 [PATCH] mutex: make mutex_lock_nested an inline function Arnd Bergmann
2015-10-13 20:30 ` Arnd Bergmann
2015-10-13 20:38 ` Peter Zijlstra
2015-10-13 20:38 ` Peter Zijlstra
2015-10-13 21:46 ` Arnd Bergmann
2015-10-13 21:46 ` Arnd Bergmann
2015-10-14 8:20 ` Peter Zijlstra
2015-10-14 8:20 ` Peter Zijlstra
2015-10-14 8:37 ` Peter Zijlstra
2015-10-14 8:37 ` Peter Zijlstra
2015-10-14 9:00 ` Arnd Bergmann
2015-10-14 9:00 ` Arnd Bergmann
2015-10-14 9:08 ` Peter Zijlstra
2015-10-14 9:08 ` Peter Zijlstra
2015-10-14 9:59 ` Mark Brown
2015-10-14 9:59 ` Mark Brown
2015-10-14 10:27 ` Mark Brown
2015-10-14 10:27 ` Mark Brown
2015-10-14 11:07 ` Peter Zijlstra
2015-10-14 11:07 ` Peter Zijlstra
2015-10-14 12:36 ` Mark Brown
2015-10-14 12:36 ` Mark Brown
2015-10-14 13:47 ` Peter Zijlstra
2015-10-14 13:47 ` Peter Zijlstra
2015-10-14 13:50 ` Peter Zijlstra
2015-10-14 13:50 ` Peter Zijlstra
2015-10-14 13:58 ` Ingo Molnar
2015-10-14 13:58 ` Ingo Molnar
2015-10-14 14:11 ` Mark Brown
2015-10-14 14:11 ` Mark Brown
2015-10-22 15:02 ` Arnd Bergmann
2015-10-22 15:02 ` Arnd Bergmann
2015-10-22 15:09 ` Peter Zijlstra
2015-10-22 15:09 ` Peter Zijlstra
2015-10-22 17:44 ` Russell King - ARM Linux
2015-10-22 17:44 ` Russell King - ARM Linux
2015-10-27 18:13 ` Ingo Molnar [this message]
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=20151027181351.GA15015@gmail.com \
--to=mingo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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.