On Thu, Aug 6, 2020 at 8:25 PM Alex Shi <alex....@linux.alibaba.com> wrote:
>
>
>
> 在 2020/8/7 上午2:38, Alexander Duyck 写道:
> >> +
> >> isolate_abort:
> >> if (locked)
> >> spin_unlock_irqrestore(&pgdat->lru_lock, flags);
> >> + if (page) {
> >> + SetPageLRU(page);
> >> + put_page(page);
> >> + }
> >>
> >> /*
> >> * Updated the cached scanner pfn once the pageblock has been
> >> scanned
> > We should probably be calling SetPageLRU before we release the lru
> > lock instead of before. It might make sense to just call it before we
> > get here, similar to how you did in the isolate_fail_put case a few
> > lines later. Otherwise this seems to violate the rules you had set up
> > earlier where we were only going to be setting the LRU bit while
> > holding the LRU lock.
>
> Hi Alex,
>
> Set out of lock here should be fine. I never said we must set the bit in
> locking.
> And this page is get by get_page_unless_zero(), no warry on release.
>
> Thanks
> Alex
I wonder if this entire section shouldn't be restructured. This is the
only spot I can see where we are resetting the LRU flag instead of
pulling the page from the LRU list with the lock held. Looking over
the code it seems like something like that should be possible. I am
not sure the LRU lock is really protecting us in either the
PageCompound check nor the skip bits. It seems like holding a
reference on the page should prevent it from switching between
compound or not, and the skip bits are per pageblock with the LRU bits
being per node/memcg which I would think implies that we could have
multiple LRU locks that could apply to a single skip bit.
