All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>,
	Julian Sun <sunjunchao@bytedance.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	 Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	 Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	 Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	 Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org,  cgroups@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH 4/4] writeback: report a slow writeback wait once per timeout
Date: Mon, 9 Nov 2026 08:44:17 -0800	[thread overview]
Message-ID: <avH2FWw6-N8s03Zb@gmail.com> (raw)
In-Reply-To: <xehz3f62chf5ivwbh7f5chapypp5md5vasdtsnxfwzsebontf3@roqs5cwjk2va>

Hello Jan,

On Mon, Nov 09, 2026 at 03:12:16PM +0100, Jan Kara wrote:
> > Once per timeout is also how often the hung task detector checks by
> > default, and patch 3 logs the total once the wait ends, so maybe that is
> > exactly what people need? Not sure.
> 
> I was mostly making jokes here. I agree reporting once per hung-task
> timeout makes more sense.

you got me here. ;-P

> > > Is this change substantially different from
> > > writeback_sb_inodes() waking up done->waitq less frequently?
> > 
> > You mean the ->progress_stamp field? That is not used for reporting
> > purposes, right? Should it be?
> 
> So my thinking was: If we change the wake up condition in
> writeback_sb_inodes() to use HZ * timeout as a limit instead of HZ *
> timeout / 2, then we should get one report per timeout, shouldn't we?

I think so. Let me hack it up and respin.

> > It could drop the duplicates: a wakeup with work left runs the
> > wait_event() condition twice (since 84654c7f4730, it is checked right
> > after schedule() and again after prepare_to_wait_event()), and the
> > second check would find ->progress_stamp just refreshed by the first.
> > 
> > But the waiter refreshes ->progress_stamp on every wakeup, so it cannot
> > space the reports further apart than the wakeups, and those have to
> > come more often than the hung task timeout.
> 
> Why do we want to wake up more often than hung task timeout? We evaluate
> the condition after each inode so the error shouldn't be that big?

Yeah, I don't think we want to wake up more often than the hung task
timeout. That should be enough here, honestly.

Thanks for the review,
--breno

      reply	other threads:[~2026-11-09 16:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 12:26 [PATCH 0/4] writeback: make slow writeback report more actionable Breno Leitao
2026-11-06 12:26 ` [PATCH 1/4] writeback: add the missing newline to the slow writeback report Breno Leitao
2026-11-06 14:18   ` Jan Kara
2026-11-06 12:26 ` [PATCH 2/4] writeback: name the bdi in " Breno Leitao
2026-11-06 14:27   ` Jan Kara
2026-11-06 15:48     ` Breno Leitao
2026-11-06 12:26 ` [PATCH 3/4] writeback: log the end of a slow writeback wait Breno Leitao
2026-11-06 14:29   ` Jan Kara
2026-11-06 12:26 ` [PATCH 4/4] writeback: report a slow writeback wait once per timeout Breno Leitao
2026-11-06 14:37   ` Jan Kara
2026-11-06 15:47     ` Breno Leitao
2026-11-09 14:12       ` Jan Kara
2026-11-09 16:44         ` Breno Leitao [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=avH2FWw6-N8s03Zb@gmail.com \
    --to=leitao@debian.org \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=kernel-team@meta.com \
    --cc=liam@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=sunjunchao@bytedance.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --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 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.