[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231221123028.gzkqd43bmdupcekz@quack3>
Date: Thu, 21 Dec 2023 13:30:28 +0100
From: Jan Kara <jack@...e.cz>
To: Christoph Hellwig <hch@....de>
Cc: Jan Kara <jack@...e.cz>, linux-mm@...ck.org,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Jan Kara <jack@...e.com>, David Howells <dhowells@...hat.com>,
Brian Foster <bfoster@...hat.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/17] writeback: Factor writeback_get_batch() out of
write_cache_pages()
On Thu 21-12-23 13:22:33, Christoph Hellwig wrote:
> On Thu, Dec 21, 2023 at 12:17:43PM +0100, Jan Kara wrote:
> > > +static void writeback_get_batch(struct address_space *mapping,
> > > + struct writeback_control *wbc)
> > > +{
> > > + folio_batch_release(&wbc->fbatch);
> > > + cond_resched();
> >
> > I'd prefer to have cond_resched() explicitely in the writeback loop instead
> > of hidden here in writeback_get_batch() where it logically does not make
> > too much sense to me...
>
> Based on the final state after this series, where would you place it?
I guess writeback_get_folio() would be fine... Which is where it naturally
lands with the inlining I already suggested so probably nothing to do here.
> (That beeing said there is a discussion underway on lkml to maybe
> kill cond_resched entirely as part of sorting out the preemption
> model mess, at that point this would become a moot point anyway)
>
> > > } else {
> > > - index = wbc->range_start >> PAGE_SHIFT;
> > > + wbc->index = wbc->range_start >> PAGE_SHIFT;
> > > end = wbc->range_end >> PAGE_SHIFT;
> > > }
> >
> > Maybe we should have:
> > end = wbc_end(wbc);
> >
> > when we have the helper? But I guess this gets cleaned up in later patches
> > anyway so whatever.
>
> Yeah, this end just goes away. I can convert it here, but that feels
> like pointless churn to me.
Agreed. Just leave it alone.
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists