On Tue, 10 May 2022 16:47:12 +0100 Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > On Thu, May 05, 2022 at 06:32:50PM -0700, Andrew Morton wrote: > > +++ a/mm/vmscan.c > > @@ -1598,40 +1598,42 @@ retry: > > stat->nr_congested += nr_pages; > > > > /* > > - * If a page at the tail of the LRU is under writeback, there > > + * If a folio at the tail of the LRU is under writeback, there > > * are three cases to consider. > > * > > - * 1) If reclaim is encountering an excessive number of pages > > - * under writeback and this page is both under writeback and > > - * PageReclaim then it indicates that pages are being queued > > - * for IO but are being recycled through the LRU before the > > - * IO can complete. Waiting on the page itself risks an > > - * indefinite stall if it is impossible to writeback the > > - * page due to IO error or disconnected storage so instead > > - * note that the LRU is being scanned too quickly and the > > - * caller can stall after page list has been processed. > > + * 1) If reclaim is encountering an excessive number of folios > > + * under writeback and this folio is both under > > + * writeback and has the reclaim flag set then it > > + * indicates that folios are being queued for I/O but > > + * are being recycled through the LRU before the I/O > > + * can complete. Waiting on the folio itself risks an > > + * indefinite stall if it is impossible to writeback > > + * the folio due to I/O error or disconnected storage > > + * so instead note that the LRU is being scanned too > > + * quickly and the caller can stall after the folio > > + * list has been processed. > > * > > At some point between this email being sent and what's currently in > linux-next, the above asterisk changed to a hash (* -> #). You may > or may not want to fix that. I looked everywhere and cannot find this #?
