linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Bernardo Innocenti <bernie@develer.com>,
	"torvalds@linux-foundation.org Abd-Alrhman Masalkhi" 
	<abd.masalkhi@gmail.com>, Jens Axboe <axboe@kernel.dk>,
	linux-block <linux-block@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Parisc List <linux-parisc@vger.kernel.org>
Subject: Re: div_u64/do_div stack size usage, was Re: [v3] block: Removed a warning while compiling with a cross compiler for parisc
Date: Tue, 6 Jul 2021 19:35:05 +0200	[thread overview]
Message-ID: <CAK8P3a2mAQOnTxBhVzVA8q8O-uVrdidCN5h5-T2dc0=Wet2uPQ@mail.gmail.com> (raw)
In-Reply-To: <YOSMct1YHs++E1vt@infradead.org>

On Tue, Jul 6, 2021 at 7:03 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Jul 06, 2021 at 05:30:54PM +0200, Abd-Alrhman Masalkhi wrote:
> > Thank you for your comment, the div_u64 function is called 5 times
> > inside diskstats_show function, so I have made a test case; I have
> > replaced one call with a constant number then I have compiled the
> > kernel, the result was instead of emitting "the frame size of 1656
> > bytes is larger than 1280 bytes" warning, it has emitted "the frame
> > size of 1328 bytes is larger than 1280 bytes" warning, so I came to the
> > conclusion that each call to div_u64 will add 328 bytes to the stack
> > frame of diskstats_show function, since it is an inlined function. so I
> > thought it might be the solution that to preventing div_u64 to be
> > inlined in diskstats_show function.
>
> Adding a bunch of relevant parties to the CC list - any idea how we
> can make the generic do_div / div_u64 not use up such gigantic amounts
> of stack?

I've seen variations of this problem many times, though usually not
involving do_div().

My guess is that this is happening here because of a combination of
things, most of the time it doesn't get nearly as bad:

- parisc has larger stack frames than others
- ilog2() as used in __div64_const32() is somewhat unreliable, it may
  end up determining that its input is a __builtin_constant_p(), but then
  still produce code for the non-constant case when the caller is
  only partially inlined
- Some compiler options make the problem worse by increasing the
  pressure on the register allocator.
- Some compiler targets don't deal well with register pressure and
  use more stack slots than they really should.

If you have the .config file that triggers this and the exact compiler
version, I can have a closer look to narrow down which of these
are part of the problem for that particular file.

One thing we did on ARM OABI (which does not deal well with
64-bit math) was to turn off the inline version of __arch_xprod_64
and instead use an extern function for do_div().

       Arnd

  reply	other threads:[~2021-07-06 19:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-06 11:19 [PATCH v3] block: Removed a warning while compiling with a cross compiler for parisc Abd-Alrhman Masalkhi
2021-07-06 13:59 ` Christoph Hellwig
2021-07-06 15:30   ` [v3] " Abd-Alrhman Masalkhi
2021-07-06 17:01     ` div_u64/do_div stack size usage, was " Christoph Hellwig
2021-07-06 17:35       ` Arnd Bergmann [this message]
2021-07-06 20:59         ` Abd-Alrhman Masalkhi
2021-07-07  8:17           ` Arnd Bergmann
2021-07-07 13:36             ` Helge Deller
2021-07-07 20:39               ` Arnd Bergmann
2021-07-08  9:29                 ` Helge Deller
2021-07-08 11:37                   ` Arnd Bergmann
2021-07-08 15:01                     ` John David Anglin
2021-07-07 14:36             ` John David Anglin
2021-07-07 15:30             ` Abd-Alrhman Masalkhi

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='CAK8P3a2mAQOnTxBhVzVA8q8O-uVrdidCN5h5-T2dc0=Wet2uPQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=abd.masalkhi@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=bernie@develer.com \
    --cc=dan.carpenter@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@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;
as well as URLs for NNTP newsgroup(s).