From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Shi Subject: Re: [PATCH v20 08/20] mm: page_idle_get_page() does not need lru_lock Date: Fri, 6 Nov 2020 09:11:12 +0800 Message-ID: References: <1603968305-8026-1-git-send-email-alex.shi@linux.alibaba.com> <1603968305-8026-9-git-send-email-alex.shi@linux.alibaba.com> <20201102144110.GB724984@cmpxchg.org> <20201102144927.GN27442@casper.infradead.org> <20201102202003.GA740958@cmpxchg.org> <20201104174603.GB744831@cmpxchg.org> <6eea82d8-e406-06ee-2333-eb6e2f1944e5@linux.alibaba.com> <20201105045702.GI17076@casper.infradead.org> <1e8f0162-cf2e-03eb-e7e0-ccc9f6a3eaf2@linux.alibaba.com> <20201105153649.GC744831@cmpxchg.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20201105153649.GC744831-druUgvl0LCNAfugRpC6u6w@public.gmane.org> List-ID: Content-Type: text/plain; charset="utf-8" To: Johannes Weiner Cc: Matthew Wilcox , akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org, daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, iamjoonsoo.kim-Hm3cg6mZ9cc@public.gmane.org, richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org, alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, rong.a.chen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, mhocko-IBi9RG/b67k@public.gmane.org, vdavydov.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, shy828301-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Vlastimil Babka , Minchan Kim 在 2020/11/5 下午11:36, Johannes Weiner 写道: >>> */ >>> > Yeah, I don't think this scenario warrants the full race diagram in > the code itself. > > But the code is highly specific - synchronizing one struct page member > for one particular use case. Let's keep at least a reference to what > we are synchronizing against. There is a non-zero chance that if the > comment goes out of date, so does the code. How about this? > > /* > * page_idle does a lockless/optimistic rmap scan on page->mapping. > * Make sure the compiler doesn't split the stores of anon_vma and > * the PAGE_MAPPING_ANON type identifier, otherwise the rmap code > * could mistake the mapping for a struct address_space and crash. > */ Thanks a lot to you all. I will update to v21 patch Alex