[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230425080052.63dik4aadlrjvd2p@techsingularity.net>
Date: Tue, 25 Apr 2023 09:00:52 +0100
From: Mel Gorman <mgorman@...hsingularity.net>
To: Doug Anderson <dianders@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>, Ying <ying.huang@...el.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Yu Zhao <yuzhao@...gle.com>, linux-fsdevel@...r.kernel.org,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 1/4] mm/filemap: Add folio_lock_timeout()
On Mon, Apr 24, 2023 at 09:22:55AM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 24, 2023 at 1:22???AM Mel Gorman <mgorman@...hsingularity.net> wrote:
> >
> > > @@ -1295,10 +1296,13 @@ static inline int folio_wait_bit_common(struct folio *folio, int bit_nr,
> > > /* Loop until we've been woken or interrupted */
> > > flags = smp_load_acquire(&wait->flags);
> > > if (!(flags & WQ_FLAG_WOKEN)) {
> > > + if (!timeout)
> > > + break;
> > > +
> >
> > An io_schedule_timeout of 0 is valid so why the special handling? It's
> > negative timeouts that cause schedule_timeout() to complain.
>
> It's not expected that the caller passes in a timeout of 0 here. The
> test here actually handles the case that the previous call to
> io_schedule_timeout() returned 0. In my patch, after the call to
> io_schedule_timeout() we unconditionally "continue" and end up back at
> the top of the loop. The next time through the loop if we don't see
> the WOKEN flag then we'll check for the two "error" conditions
> (timeout or signal pending) and break for either of them.
Ah, I see!
>
> To make it clearer, I'll add this comment for the next version:
>
> /* Break if the last io_schedule_timeout() said no time left */
Yes please.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists