From: Marek Vasut <marek.vasut@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Cc: stable@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: cfi: convert inline functions to macros
Date: Wed, 11 Oct 2017 23:34:33 +0200 [thread overview]
Message-ID: <b109f253-ac22-82b0-6716-6a069eb3e4f2@gmail.com> (raw)
In-Reply-To: <20171011135419.3492681-1-arnd@arndb.de>
On 10/11/2017 03:54 PM, Arnd Bergmann wrote:
> The map_word_() functions, dating back to linux-2.6.8, try to perform
> bitwise operations on a 'map_word' structure. This may have worked
> with compilers that were current then (gcc-3.4 or earlier), but end
> up being rather inefficient on any version I could try now (gcc-4.4 or
> higher). Specifically we hit a problem analyzed in gcc PR81715 where we
> fail to reuse the stack space for local variables.
>
> This can be seen immediately in the stack consumption for
> cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
> can be up to 2200 bytes. Changing the inline functions into macros brings
> this down to 1280 bytes. Without KASAN, the same problem exists, but
> the stack consumption is lower to start with, my patch shrinks it from
> 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
> 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
> structures for each call to one of these helpers.
>
> With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
> but nobody uses that yet, so we should still work around it in mainline
> kernels and probably backport the workaround to stable kernels as well.
> We had a couple of other functions that suffered from the same gcc bug,
> and all of those had a simpler workaround involving dummy variables
> in the inline function. Unfortunately that did not work here, the
> macro hack was the best I could come up with.
>
> It would also be helpful to have someone to a little performance testing
> on the patch, to see how much it helps in terms of CPU utilitzation.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Don't you lose type-checking with this conversion to macros ?
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2017-10-11 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 13:54 [PATCH] mtd: cfi: convert inline functions to macros Arnd Bergmann
2017-10-11 21:34 ` Marek Vasut [this message]
2017-12-17 8:43 ` Boris Brezillon
2017-12-17 19:34 ` Marek Vasut
2017-12-17 20:34 ` Richard Weinberger
2017-12-18 9:16 ` Arnd Bergmann
2017-12-18 9:18 ` Marek Vasut
2017-12-18 10:29 ` Arnd Bergmann
2017-12-18 10:38 ` Marek Vasut
2017-12-18 16:25 ` Boris Brezillon
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=b109f253-ac22-82b0-6716-6a069eb3e4f2@gmail.com \
--to=marek.vasut@gmail.com \
--cc=arnd@arndb.de \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=stable@vger.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