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.
