On Thu, Aug 20, 2020 at 2:58 AM Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx> wrote: > > > > 在 2020/8/19 下午10:42, Alexander Duyck 写道: > >> It's actually changed the meaning from current func. which I had seen a bug if no relock. > >> but after move to 5.9 kernel, I can not reprodce the bug any more. I am not sure if 5.9 fixed > >> the problem, and we don't need relock here. > > So I am not sure what you mean here about "changed the meaning from > > the current func". Which function are you referring to and what > > changed? > > > > From what I can tell the pages cannot change memcg because they were > > isolated and had the LRU flag stripped. They shouldn't be able to > > change destination LRU vector as a result. Assuming that, then they > > can all be processed under same LRU lock and we can avoid having to > > release it until we are forced to do so to call putback_lru_page or > > destroy the compound pages that were freed while we were shrinking the > > LRU lists. > > > > I had sent a bug which base on 5.8 kernel. > https://lkml.org/lkml/2020/7/28/465 > > I am not sure it was fixed in new kernel. The original line was introduced by Hugh Dickins > I believe it would be great if you can get comments from him. When I brought this up before you had pointed to the relocking being due to the fact that the function was reacquiring the lruvec for some reason. I wonder if the fact that the LRU bit stripping serializing things made it so that the check for the lruvec after releasing the lock became redundant. - Alex
