Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: David Sterba <dsterba@suse.cz>
Cc: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Remove noinline attribute from wait_for_commit
Date: Wed, 25 Nov 2020 12:51:32 +0100	[thread overview]
Message-ID: <20201125115132.GC6430@twin.jikos.cz> (raw)
In-Reply-To: <20201124160532.GA6430@twin.jikos.cz>

On Tue, Nov 24, 2020 at 05:05:32PM +0100, David Sterba wrote:
> On Tue, Nov 24, 2020 at 05:42:57PM +0200, Nikolay Borisov wrote:
> > On 24.11.20 г. 17:39 ч., David Sterba wrote:
> > > On Tue, Nov 24, 2020 at 04:45:02PM +0200, Nikolay Borisov wrote:
> > >> The function is a plain wrapper that noinline makes no sense.
> > > 
> > > Or it is a way to let the function name appear in a stack trace, which
> > > could be useful for debugging or analyzing system state.
> > > 
> > 
> > Well, this information could generally be derived by having the debug
> > info  either in crash or one of the "beautify" scripts. In any case I
> > won't insist.
> 
> The way it's used is 'cat /proc/*/stack', without the need of debugging
> kernels and not in a post-mortem analysis with crash.

Actually, there's noinline_for_stack annotation that could make a bit
more understandable, but reading the comment it's more about conserving
stack space, not making the function visible in stack trace.

There are functions like free_reloc_roots, memcmp_node_keys or
cleanup_bitmap_list that do a trivial operations, no chance to block or
wait. So these are the obvious cases where we don't want it, there are
still many more for long functions that would need closer inspection.

      reply	other threads:[~2020-11-25 11:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 14:45 [PATCH] btrfs: Remove noinline attribute from wait_for_commit Nikolay Borisov
2020-11-24 15:39 ` David Sterba
2020-11-24 15:42   ` Nikolay Borisov
2020-11-24 16:05     ` David Sterba
2020-11-25 11:51       ` David Sterba [this message]

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=20201125115132.GC6430@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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