Re: Optimizing small reads

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 14 Oct 2025 at 05:58, Kiryl Shutsemau <kirill@shutemov.name> wrote:
>
> clang-19 actually does pretty good job re-using stack space without
> additional function call.

Hmm. That certainly didn't always use to be the case. We've had lots
of issues with things like ioctl's that have multiple entirely
independent structures for different cases - so obviously no lifetime
overlap - and it has caused lots of extra stack use.

We do use -fconserve-stack these days and maybe that fixed the
problems we used to have with duplicate stack slots.

Or maybe it's just "different compiler versions".

But the case I was worried about wasn't so much the "re-use stack
space" as simply "lots of stack space for one case that wants it, deep
call chain for the other case".

But it appears we're ok:

> And if we increase buffer size to 1k Clang uninlines it:
>
> ../mm/filemap.c:2870:9:filemap_read     32      static
> ../mm/filemap.c:2714:13:filemap_read_fast       1168    static
> ../mm/filemap.c:2750:16:filemap_read_slow       384     static
>
> gcc-14, on other hand, doesn't want to inline these functions, even with
> 'inline' specified. And '__always_inline' doesn't look good.

That looks good. I'm still 100% sure we absolutely have had issues in
this area, but again, it might be -fconserve-stack that ends up making
the compilers do the right thing. Because that sets some stack frame
growth boundaries.

           Linus