linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] fs: ratelimit __find_get_block_slow() failure message.
Date: Fri, 11 Jan 2019 11:19:45 +0100	[thread overview]
Message-ID: <CACT4Y+YsuGt32H=_UTXjj-d7fEe6Lo4Nw91R-rZPy1zOyiJ4OA@mail.gmail.com> (raw)
In-Reply-To: <1547201433-10231-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>

On Fri, Jan 11, 2019 at 11:10 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> When something let __find_get_block_slow() hit all_mapped path, it calls
> printk() for 100+ times per a second. But there is no need to print same
> message with such high frequency; it is just asking for stall warning, or
> at least bloating log files.
>
>   [  399.866302][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
>   [  399.873324][T15342] b_state=0x00000029, b_size=512
>   [  399.878403][T15342] device loop0 blocksize: 4096
>   [  399.883296][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
>   [  399.890400][T15342] b_state=0x00000029, b_size=512
>   [  399.895595][T15342] device loop0 blocksize: 4096
>   [  399.900556][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8
>   [  399.907471][T15342] b_state=0x00000029, b_size=512
>   [  399.912506][T15342] device loop0 blocksize: 4096
>
> This patch reduces frequency to approximately once per a second, in
> addition to concatenating three lines into one. This patch uses plain
> time_in_range() than __ratelimit(), for there is no need to allocate
> space for debug objects in ratelimit_state.lock field.
>
>   [  399.866302][T15342] __find_get_block_slow() failed. block=1, b_blocknr=8, b_state=0x00000029, b_size=512, device loop0 blocksize: 4096
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
>  fs/buffer.c | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 52d024b..3fc9167 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -200,6 +200,7 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate)
>         struct buffer_head *head;
>         struct page *page;
>         int all_mapped = 1;
> +       static unsigned long last;

/\/\/\/\/\/\

We will have to re-fix this when we start testing with KTSAN, data
race detector.

>         index = block >> (PAGE_SHIFT - bd_inode->i_blkbits);
>         page = find_get_page_flags(bd_mapping, index, FGP_ACCESSED);
> @@ -227,15 +228,13 @@ void end_buffer_write_sync(struct buffer_head *bh, int uptodate)
>          * file io on the block device and getblk.  It gets dealt with
>          * elsewhere, don't buffer_error if we had some unmapped buffers
>          */
> -       if (all_mapped) {
> -               printk("__find_get_block_slow() failed. "
> -                       "block=%llu, b_blocknr=%llu\n",
> -                       (unsigned long long)block,
> -                       (unsigned long long)bh->b_blocknr);
> -               printk("b_state=0x%08lx, b_size=%zu\n",
> -                       bh->b_state, bh->b_size);
> -               printk("device %pg blocksize: %d\n", bdev,
> -                       1 << bd_inode->i_blkbits);
> +       if (all_mapped && !time_in_range(jiffies, last, last + HZ)) {
> +               printk("__find_get_block_slow() failed. block=%llu, b_blocknr=%llu, b_state=0x%08lx, b_size=%zu, device %pg blocksize: %d\n",
> +                      (unsigned long long)block,
> +                      (unsigned long long)bh->b_blocknr,
> +                      bh->b_state, bh->b_size, bdev,
> +                      1 << bd_inode->i_blkbits);
> +               last = jiffies;
>         }
>  out_unlock:
>         spin_unlock(&bd_mapping->private_lock);
> --
> 1.8.3.1

  reply	other threads:[~2019-01-11 10:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 10:10 [PATCH] fs: ratelimit __find_get_block_slow() failure message Tetsuo Handa
2019-01-11 10:19 ` Dmitry Vyukov [this message]
     [not found]   ` <04c6d87c-fc26-b994-3b34-947414984abe@i-love.sakura.ne.jp>
2019-01-11 10:40     ` Dmitry Vyukov
2019-01-11 10:48       ` Dmitry Vyukov
2019-01-11 12:46         ` Tetsuo Handa
2019-01-16  9:47           ` Dmitry Vyukov
2019-01-16 10:43             ` Jan Kara
2019-01-16 11:03               ` Dmitry Vyukov
2019-01-16 11:48                 ` Dmitry Vyukov
2019-01-16 16:28                   ` Greg Kroah-Hartman
2019-01-17 13:18                     ` Dmitry Vyukov
2019-01-21  8:37                       ` Jan Kara
2019-01-21 10:33                         ` Tetsuo Handa
2019-01-21 10:48                           ` Greg Kroah-Hartman
2019-01-22 15:27                         ` Kernel development process (was: [PATCH] fs: ratelimit __find_get_block_slow() failure message.) Dmitry Vyukov
2019-01-22 17:15                           ` Jan Kara
2019-01-16 11:56                 ` [PATCH] fs: ratelimit __find_get_block_slow() failure message Jan Kara
2019-01-16 12:37                   ` Dmitry Vyukov
2019-01-16 12:37                     ` Dmitry Vyukov
2019-01-16 14:51                     ` Jan Kara
2019-01-16 14:51                       ` Jan Kara
2019-01-16 15:33                       ` Dmitry Vyukov
2019-01-16 15:33                         ` Dmitry Vyukov
2019-01-16 16:15                         ` Paul E. McKenney
2019-01-16 16:15                           ` Paul E. McKenney
2019-01-17 14:11               ` Tetsuo Handa
2019-01-18 15:30                 ` Dmitry Vyukov
2019-01-11 10:51       ` Tetsuo Handa
2019-01-11 11:03 ` Jan Kara
2019-01-11 11:37   ` [PATCH v2] " Tetsuo Handa
2019-01-21  8:57     ` Jan Kara

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='CACT4Y+YsuGt32H=_UTXjj-d7fEe6Lo4Nw91R-rZPy1zOyiJ4OA@mail.gmail.com' \
    --to=dvyukov@google.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=viro@zeniv.linux.org.uk \
    /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).