On 7/31/19 11:11 PM, Mike Kravetz wrote: > On 7/31/19 4:08 AM, Vlastimil Babka wrote: >> >> I agree this is an improvement overall, but perhaps the patch does too >> many things at once. The reshuffle is one thing and makes sense. The >> change of the last return condition could perhaps be separate. Also >> AFAICS the ultimate result is that when nr_reclaimed == 0, the function >> will now always return false. Which makes the initial test for >> __GFP_RETRY_MAYFAIL and the comments there misleading. There will no >> longer be a full LRU scan guaranteed - as long as the scanned LRU chunk >> yields no reclaimed page, we abort. > > Can someone help me understand why nr_scanned == 0 guarantees a full > LRU scan? FWICS, nr_scanned used in this context is only incremented > in shrink_page_list and potentially shrink_zones. In the stall case I > am looking at, there are MANY cases in which nr_scanned is only a few > pages and none of those are reclaimed. > > Can we not get nr_scanned == 0 on an arbitrary chunk of the LRU? > > I must be missing something, because I do not see how nr_scanned == 0 > guarantees a full scan. Yeah, seems like it doesn't. More reasons to update/remove the comment. Can be a followup cleanup if you don't want to block the series.
