On Wed, Aug 5, 2020 at 6:54 PM Alex Shi [off-list ref] wrote:

在 2020/8/6 上午6:43, Alexander Duyck 写道:

quoted

quoted

@@ -878,9 +877,8 @@ void release_pages(struct page **pages, int nr)
                                spin_lock_irqsave(&locked_pgdat->lru_lock, flags);
                        }

-                       lruvec = mem_cgroup_page_lruvec(page, locked_pgdat);
-                       VM_BUG_ON_PAGE(!PageLRU(page), page);
                        __ClearPageLRU(page);
+                       lruvec = mem_cgroup_page_lruvec(page, locked_pgdat);
                        del_page_from_lru_list(page, lruvec, page_off_lru(page));
                }

The more I look at this piece it seems like this change wasn't really
necessary. If anything it seems like it could catch potential bugs as
it was testing for the PageLRU flag before and then clearing it
manually anyway. In addition it doesn't reduce the critical path by
any significant amount so I am not sure these changes are providing
any benefit.

Don't know hat kind of bug do you mean here, since the page is no one using, means
no one could ClearPageLRU in other place,  so if you like to keep the VM_BUG_ON_PAGE,
that should be ok.

You kind of answered your own question. Basically the bug it would
catch is if another thread were to clear the flag without getting a
reference to the page first. My preference would be to leave this code
as is for now. There isn't much value in either moving the lruvec or
removing the VM_BUG_ON_PAGE call since the critical path size would
barely be effected as it is only one or two operations anyway. What it
comes down to is that the less unnecessary changes we make the better.