lkml.org 
[lkml]   [2021]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux 5.16-rc1
Date


> 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


\
 
 \ /
  Last update: 2021-11-16 01:09    [W:1.004 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site