All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Terrell <terrelln@fb.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Nick Terrell <nickrterrell@gmail.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.16-rc1
Date: Mon, 15 Nov 2021 20:39:22 +0000	[thread overview]
Message-ID: <8023FCC7-E59E-478F-92F5-3E6581E75D48@fb.com> (raw)
In-Reply-To: <CAHk-=wgm-Co+ys0TQKZ8aRp-NGTb+ER-VFmEOEVamH724cWwFQ@mail.gmail.com>



> On Nov 15, 2021, at 9:53 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Mon, Nov 15, 2021 at 9:07 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> 
>> Top of tree is a bit better:
> 
> Thanks for re-testing.
> 
> That doesn't actually look all that bad for -rc1.  Several of them
> already have fixes, and most of the rest look "easily fixable".
> 
> Famous last words.
> 
> The most worrisome ones are probably the stack frame complaint ones
> (libzstd and a couple of powerpc ones) that Geert also reported, but
> they might at least to some degree be as simple as just due to the
> same excessive inlining that was already fingered for the code bloat.
> 
> But it could be more fundamental - the kernel just doesn't like stack
> allocations the same way user space does, so the sync-up to a newer
> libzstd might be a bit more problematic than just "don't force
> inlining".

On x86-64 I’ve measured zstd’s stack usage to be 1.6KB for compression,
this is up from 1.4KB before the change. I suspect it is a problem with these
functions on this compiler + architecture combo, where the compiler isn’t
able to inline + constant propagate + run dead code elimination. The functions
mentioned rely on these optimizations to be efficient, and I suspect if the
optimizations fail there will be a lot of unnecessary stack usage.

The solution should be to remove the dependency on compiler optimizations
for efficient stack usage in these functions. So we don’t end up with excess
stack usage on non-x86/arm architectures.

On my todo list is:

1. Reduce stack usage of the mentioned functions
2. Reduce code size bloat of lib/zstd/zstd_opt.c

I’m working on this now, and expect to have a pull request ready to go
tomorrow.

> Nick - you've been cc'd twice because you sign off your commits with
> your work email, but then seem to actually prefer the personal one, so
> I didn't know which to use and just added both. See

Sorry for the confusion. Both work, but I prefer my work email.

>  https://lore.kernel.org/lkml/652edea7-28a0-70d9-c63f-d910b5942454@roeck-us.net/
>  https://lore.kernel.org/lkml/20211115155105.3797527-1-geert@linux-m68k.org
> 
> if you didn't already.
> 
>               Linus

Best,
Nick Terrell



  reply	other threads:[~2021-11-16  0:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-14 22:28 Linux 5.16-rc1 Linus Torvalds
2021-11-15  3:17 ` linux-next: stats (Was: Linux 5.16-rc1) Stephen Rothwell
2021-11-15 18:02   ` is arch/h8300 dead, was " Christoph Hellwig
2021-11-15  4:56 ` Linux 5.16-rc1 Guenter Roeck
2021-11-15  5:21   ` Linus Torvalds
2021-11-15  6:33     ` Guenter Roeck
2021-11-15 17:07     ` Guenter Roeck
2021-11-15 17:53       ` Linus Torvalds
2021-11-15 20:39         ` Nick Terrell [this message]
2021-11-15 18:10       ` Linus Torvalds
2021-11-15 18:19         ` Helge Deller
2021-11-15 18:38         ` Guenter Roeck
2021-11-16 11:36       ` Michael Ellerman
2021-11-16 14:50         ` Guenter Roeck
2021-11-17 20:18         ` Geert Uytterhoeven
2021-11-17 23:29           ` Anton Altaparmakov
2021-11-18  0:28             ` Linus Torvalds
2021-11-18  1:26               ` Anton Altaparmakov
2021-11-18  1:54                 ` Linus Torvalds
2021-11-18 21:23                   ` Guenter Roeck
2021-11-18 22:34                     ` Linus Torvalds
2021-11-18 23:08                       ` Guenter Roeck
2021-11-15 16:14   ` Geert Uytterhoeven

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=8023FCC7-E59E-478F-92F5-3E6581E75D48@fb.com \
    --to=terrelln@fb.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=nickrterrell@gmail.com \
    --cc=torvalds@linux-foundation.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.