From: Alex Shi <alex.shi@linux.alibaba.com> To: Hugh Dickins <hughd@google.com> Cc: Andrew Morton <akpm@linux-foundation.org>, mgorman@techsingularity.net, tj@kernel.org, khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com, willy@infradead.org, hannes@cmpxchg.org, lkp@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, shakeelb@google.com, iamjoonsoo.kim@lge.com, richard.weiyang@gmail.com, kirill@shutemov.name, alexander.duyck@gmail.com, rong.a.chen@intel.com, mhocko@suse.com, vdavydov.dev@gmail.com, shy828301@gmail.com, vbabka@suse.cz, minchan@kernel.org, cai@lca.pw Subject: Re: [PATCH v18 00/32] per memcg lru_lock: reviews Date: Sun, 13 Sep 2020 22:22:48 +0800 [thread overview] Message-ID: <2fed13c0-1d78-fa92-b607-e997b1bc5fb2@linux.alibaba.com> (raw) In-Reply-To: <alpine.LSU.2.11.2009112216260.23961@eggly.anvils> 在 2020/9/12 下午4:38, Hugh Dickins 写道: > On Wed, 9 Sep 2020, Alex Shi wrote: >> 在 2020/9/9 上午7:41, Hugh Dickins 写道: >>> >>> The use of lock_page_memcg() in __munlock_pagevec() in 20/32, >>> introduced in patchset v17, looks good but it isn't: I was lucky that >>> systemd at reboot did some munlocking that exposed the problem to lockdep. >>> The first time into the loop, lock_page_memcg() is done before lru_lock >>> (as 06/32 has allowed); but the second time around the loop, it is done >>> while still holding lru_lock. >> >> I don't know the details of lockdep show. Just wondering could it possible >> to solid the move_lock/lru_lock sequence? >> or try other blocking way which mentioned in commit_charge()? >> >>> >>> lock_page_memcg() really needs to be absorbed into (a variant of) >>> relock_page_lruvec(), and I do have that (it's awkward because of >>> the different ways in which the IRQ flags are handled). And out of >>> curiosity, I've also tried using that in mm/swap.c too, instead of the >>> TestClearPageLRU technique: lockdep is happy, but an update_lru_size() >>> warning showed that it cannot safely be mixed with the TestClearPageLRU >>> technique (that I'd left in isolate_lru_page()). So I'll stash away >>> that relock_page_lruvec(), and consider what's best for mm/mlock.c: >>> now that I've posted these comments so far, that's my priority, then >>> to get the result under testing again, before resuming these comments. >> >> No idea of your solution, but looking forward for your good news! :) > > Yes, it is good news, and simpler than anything suggested above. Awesome! > > The main difficulties will probably be to look good in the 80 columns > (I know that limit has been lifted recently, but some of us use xterms > side by side), and to explain it. > > mm/mlock.c has not been kept up-to-date very well: and in particular, > you have taken too seriously that "Serialize with any parallel > __split_huge_page_refcount()..." comment that you updated to two > comments "Serialize split tail pages in __split_huge_page_tail()...". > > Delete them! The original comment was by Vlastimil for v3.14 in 2014. > But Kirill redesigned THP refcounting for v4.5 in 2016: that's when > __split_huge_page_refcount() went away. And with the new refcounting, > the THP splitting races that lru_lock protected munlock_vma_page() > and __munlock_pagevec() from: those races have become impossible. > > Or maybe there never was such a race in __munlock_pagevec(): you > have added the comment there, assuming lru_lock was for that purpose, > but that was probably just the convenient place to take it, > to cover all the del_page_from_lru()s. > > Observe how split_huge_page_to_list() uses unmap_page() to remove > all pmds and all ptes for the huge page being split, and remap_page() > only replaces the migration entries (used for anon but not for shmem > or file) after doing all of the __split_huge_page_tail()s, before > unlocking any of the pages. Recall that munlock_vma_page() and > __munlock_pagevec() are being applied to pages found mapped > into userspace, by ptes or pmd: there are none of those while > __split_huge_page_tail() is being used, so no race to protect from. > > (Could a newly detached tail be freshly faulted into userspace just > before __split_huge_page() has reached the head? Not quite, the > fault has to wait to get the tail's page lock. But even if it > could, how would that be a problem for __munlock_pagevec()?) > > There's lots more that could be said: for example, PageMlocked will > always be clear on the THP head during __split_huge_page_tail(), > because the last unmap of a PageMlocked page does clear_page_mlock(). > But that's not required to prove the case, it's just another argument > against the "Serialize" comment you have in __munlock_pagevec(). > > So, no need for the problematic lock_page_memcg(page) there in > __munlock_pagevec(), nor to lock (or relock) lruvec just below it. > __munlock_pagevec() still needs lru_lock to del_page_from_lru_list(), > of course, but that must be done after your TestClearPageMlocked has > stabilized page->memcg. Use relock_page_lruvec_irq() here? I suppose > that will be easiest, but notice how __munlock_pagevec_fill() has > already made sure that all the pages in the pagevec are from the same > zone (and it cannot do the same for memcg without locking page memcg); > so some of relock's work will be redundant. It sounds reasonable for me. > > Otherwise, I'm much happier with your mm/mlock.c since looking at it > in more detail: a couple of nits though - drop the clear_page_mlock() > hunk from 25/32 - kernel style says do it the way you are undoing by > - if (!isolate_lru_page(page)) { > + if (!isolate_lru_page(page)) > putback_lru_page(page); > - } else { > + else { > I don't always follow that over-braced style when making changes, > but you should not touch otherwise untouched code just to make it > go against the approved style. And in munlock_vma_page(), > - if (!TestClearPageMlocked(page)) { > + if (!TestClearPageMlocked(page)) > /* Potentially, PTE-mapped THP: do not skip the rest PTEs */ > - nr_pages = 1; > - goto unlock_out; > - } > + return 0; > please restore the braces: with that comment line in there, > the compiler does not need the braces, but the human eye does. Yes, That's better to keep the brace there. Thanks Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> To: Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, mgorman-3eNAlZScCAx27rWaFMvyedHuzzzSOjJt@public.gmane.org, tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org, daniel.m.jordan-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@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, vbabka-AlSwsSmVLrQ@public.gmane.org, minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, cai-J5quhbR+WMc@public.gmane.org Subject: Re: [PATCH v18 00/32] per memcg lru_lock: reviews Date: Sun, 13 Sep 2020 22:22:48 +0800 [thread overview] Message-ID: <2fed13c0-1d78-fa92-b607-e997b1bc5fb2@linux.alibaba.com> (raw) In-Reply-To: <alpine.LSU.2.11.2009112216260.23961-fupSdm12i1nKWymIFiNcPA@public.gmane.org> 在 2020/9/12 下午4:38, Hugh Dickins 写道: > On Wed, 9 Sep 2020, Alex Shi wrote: >> 在 2020/9/9 上午7:41, Hugh Dickins 写道: >>> >>> The use of lock_page_memcg() in __munlock_pagevec() in 20/32, >>> introduced in patchset v17, looks good but it isn't: I was lucky that >>> systemd at reboot did some munlocking that exposed the problem to lockdep. >>> The first time into the loop, lock_page_memcg() is done before lru_lock >>> (as 06/32 has allowed); but the second time around the loop, it is done >>> while still holding lru_lock. >> >> I don't know the details of lockdep show. Just wondering could it possible >> to solid the move_lock/lru_lock sequence? >> or try other blocking way which mentioned in commit_charge()? >> >>> >>> lock_page_memcg() really needs to be absorbed into (a variant of) >>> relock_page_lruvec(), and I do have that (it's awkward because of >>> the different ways in which the IRQ flags are handled). And out of >>> curiosity, I've also tried using that in mm/swap.c too, instead of the >>> TestClearPageLRU technique: lockdep is happy, but an update_lru_size() >>> warning showed that it cannot safely be mixed with the TestClearPageLRU >>> technique (that I'd left in isolate_lru_page()). So I'll stash away >>> that relock_page_lruvec(), and consider what's best for mm/mlock.c: >>> now that I've posted these comments so far, that's my priority, then >>> to get the result under testing again, before resuming these comments. >> >> No idea of your solution, but looking forward for your good news! :) > > Yes, it is good news, and simpler than anything suggested above. Awesome! > > The main difficulties will probably be to look good in the 80 columns > (I know that limit has been lifted recently, but some of us use xterms > side by side), and to explain it. > > mm/mlock.c has not been kept up-to-date very well: and in particular, > you have taken too seriously that "Serialize with any parallel > __split_huge_page_refcount()..." comment that you updated to two > comments "Serialize split tail pages in __split_huge_page_tail()...". > > Delete them! The original comment was by Vlastimil for v3.14 in 2014. > But Kirill redesigned THP refcounting for v4.5 in 2016: that's when > __split_huge_page_refcount() went away. And with the new refcounting, > the THP splitting races that lru_lock protected munlock_vma_page() > and __munlock_pagevec() from: those races have become impossible. > > Or maybe there never was such a race in __munlock_pagevec(): you > have added the comment there, assuming lru_lock was for that purpose, > but that was probably just the convenient place to take it, > to cover all the del_page_from_lru()s. > > Observe how split_huge_page_to_list() uses unmap_page() to remove > all pmds and all ptes for the huge page being split, and remap_page() > only replaces the migration entries (used for anon but not for shmem > or file) after doing all of the __split_huge_page_tail()s, before > unlocking any of the pages. Recall that munlock_vma_page() and > __munlock_pagevec() are being applied to pages found mapped > into userspace, by ptes or pmd: there are none of those while > __split_huge_page_tail() is being used, so no race to protect from. > > (Could a newly detached tail be freshly faulted into userspace just > before __split_huge_page() has reached the head? Not quite, the > fault has to wait to get the tail's page lock. But even if it > could, how would that be a problem for __munlock_pagevec()?) > > There's lots more that could be said: for example, PageMlocked will > always be clear on the THP head during __split_huge_page_tail(), > because the last unmap of a PageMlocked page does clear_page_mlock(). > But that's not required to prove the case, it's just another argument > against the "Serialize" comment you have in __munlock_pagevec(). > > So, no need for the problematic lock_page_memcg(page) there in > __munlock_pagevec(), nor to lock (or relock) lruvec just below it. > __munlock_pagevec() still needs lru_lock to del_page_from_lru_list(), > of course, but that must be done after your TestClearPageMlocked has > stabilized page->memcg. Use relock_page_lruvec_irq() here? I suppose > that will be easiest, but notice how __munlock_pagevec_fill() has > already made sure that all the pages in the pagevec are from the same > zone (and it cannot do the same for memcg without locking page memcg); > so some of relock's work will be redundant. It sounds reasonable for me. > > Otherwise, I'm much happier with your mm/mlock.c since looking at it > in more detail: a couple of nits though - drop the clear_page_mlock() > hunk from 25/32 - kernel style says do it the way you are undoing by > - if (!isolate_lru_page(page)) { > + if (!isolate_lru_page(page)) > putback_lru_page(page); > - } else { > + else { > I don't always follow that over-braced style when making changes, > but you should not touch otherwise untouched code just to make it > go against the approved style. And in munlock_vma_page(), > - if (!TestClearPageMlocked(page)) { > + if (!TestClearPageMlocked(page)) > /* Potentially, PTE-mapped THP: do not skip the rest PTEs */ > - nr_pages = 1; > - goto unlock_out; > - } > + return 0; > please restore the braces: with that comment line in there, > the compiler does not need the braces, but the human eye does. Yes, That's better to keep the brace there. Thanks Alex
next prev parent reply other threads:[~2020-09-13 14:24 UTC|newest] Thread overview: 201+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-24 12:54 [PATCH v18 00/32] per memcg lru_lock Alex Shi 2020-08-24 12:54 ` [PATCH v18 01/32] mm/memcg: warning on !memcg after readahead page charged Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 02/32] mm/memcg: bail out early from swap accounting when memcg is disabled Alex Shi 2020-08-24 12:54 ` [PATCH v18 03/32] mm/thp: move lru_add_page_tail func to huge_memory.c Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 04/32] mm/thp: clean up lru_add_page_tail Alex Shi 2020-08-24 12:54 ` [PATCH v18 05/32] mm/thp: remove code path which never got into Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 06/32] mm/thp: narrow lru locking Alex Shi 2020-09-10 13:49 ` Matthew Wilcox 2020-09-10 13:49 ` Matthew Wilcox 2020-09-11 3:37 ` Alex Shi 2020-09-11 3:37 ` Alex Shi 2020-09-13 15:27 ` Matthew Wilcox 2020-09-13 15:27 ` Matthew Wilcox 2020-09-19 1:00 ` Hugh Dickins 2020-09-19 1:00 ` Hugh Dickins 2020-08-24 12:54 ` [PATCH v18 07/32] mm/swap.c: stop deactivate_file_page if page not on lru Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 08/32] mm/vmscan: remove unnecessary lruvec adding Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 09/32] mm/page_idle: no unlikely double check for idle page counting Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 10/32] mm/compaction: rename compact_deferred as compact_should_defer Alex Shi 2020-08-24 12:54 ` [PATCH v18 11/32] mm/memcg: add debug checking in lock_page_memcg Alex Shi 2020-08-24 12:54 ` [PATCH v18 12/32] mm/memcg: optimize mem_cgroup_page_lruvec Alex Shi 2020-08-24 12:54 ` [PATCH v18 13/32] mm/swap.c: fold vm event PGROTATED into pagevec_move_tail_fn Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 14/32] mm/lru: move lru_lock holding in func lru_note_cost_page Alex Shi 2020-08-24 12:54 ` [PATCH v18 15/32] mm/lru: move lock into lru_note_cost Alex Shi 2020-09-21 21:36 ` Hugh Dickins 2020-09-21 21:36 ` Hugh Dickins 2020-09-21 21:36 ` Hugh Dickins 2020-09-21 22:03 ` Hugh Dickins 2020-09-21 22:03 ` Hugh Dickins 2020-09-22 3:39 ` Alex Shi 2020-09-22 3:39 ` Alex Shi 2020-09-22 3:38 ` Alex Shi 2020-09-22 3:38 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 16/32] mm/lru: introduce TestClearPageLRU Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-09-21 23:16 ` Hugh Dickins 2020-09-21 23:16 ` Hugh Dickins 2020-09-21 23:16 ` Hugh Dickins 2020-09-22 3:53 ` Alex Shi 2020-09-22 3:53 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 17/32] mm/compaction: do page isolation first in compaction Alex Shi 2020-09-21 23:49 ` Hugh Dickins 2020-09-21 23:49 ` Hugh Dickins 2020-09-22 4:57 ` Alex Shi 2020-09-22 4:57 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 18/32] mm/thp: add tail pages into lru anyway in split_huge_page() Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 19/32] mm/swap.c: serialize memcg changes in pagevec_lru_move_fn Alex Shi 2020-09-22 0:42 ` Hugh Dickins 2020-09-22 0:42 ` Hugh Dickins 2020-09-22 0:42 ` Hugh Dickins 2020-09-22 5:00 ` Alex Shi 2020-09-22 5:00 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 20/32] mm/lru: replace pgdat lru_lock with lruvec lock Alex Shi 2020-09-22 5:27 ` Hugh Dickins 2020-09-22 5:27 ` Hugh Dickins 2020-09-22 5:27 ` Hugh Dickins 2020-09-22 8:58 ` Alex Shi 2020-09-22 8:58 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 21/32] mm/lru: introduce the relock_page_lruvec function Alex Shi 2020-09-22 5:40 ` Hugh Dickins 2020-09-22 5:40 ` Hugh Dickins 2020-09-22 5:40 ` Hugh Dickins 2020-08-24 12:54 ` [PATCH v18 22/32] mm/vmscan: use relock for move_pages_to_lru Alex Shi 2020-09-22 5:44 ` Hugh Dickins 2020-09-22 5:44 ` Hugh Dickins 2020-09-23 1:55 ` Alex Shi 2020-09-23 1:55 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 23/32] mm/lru: revise the comments of lru_lock Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-09-22 5:48 ` Hugh Dickins 2020-09-22 5:48 ` Hugh Dickins 2020-08-24 12:54 ` [PATCH v18 24/32] mm/pgdat: remove pgdat lru_lock Alex Shi 2020-09-22 5:53 ` Hugh Dickins 2020-09-22 5:53 ` Hugh Dickins 2020-09-23 1:55 ` Alex Shi 2020-09-23 1:55 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 25/32] mm/mlock: remove lru_lock on TestClearPageMlocked in munlock_vma_page Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-26 5:52 ` Alex Shi 2020-08-26 5:52 ` Alex Shi 2020-09-22 6:13 ` Hugh Dickins 2020-09-22 6:13 ` Hugh Dickins 2020-09-22 6:13 ` Hugh Dickins 2020-09-23 1:58 ` Alex Shi 2020-09-23 1:58 ` Alex Shi 2020-08-24 12:54 ` [PATCH v18 26/32] mm/mlock: remove __munlock_isolate_lru_page Alex Shi 2020-08-24 12:54 ` Alex Shi 2020-08-24 12:55 ` [PATCH v18 27/32] mm/swap.c: optimizing __pagevec_lru_add lru_lock Alex Shi 2020-08-24 12:55 ` Alex Shi 2020-08-26 9:07 ` Alex Shi 2020-08-24 12:55 ` [PATCH v18 28/32] mm/compaction: Drop locked from isolate_migratepages_block Alex Shi 2020-08-24 12:55 ` [PATCH v18 29/32] mm: Identify compound pages sooner in isolate_migratepages_block Alex Shi 2020-08-24 12:55 ` Alex Shi 2020-08-24 12:55 ` [PATCH v18 30/32] mm: Drop use of test_and_set_skip in favor of just setting skip Alex Shi 2020-08-24 12:55 ` [PATCH v18 31/32] mm: Add explicit page decrement in exception path for isolate_lru_pages Alex Shi 2020-08-24 12:55 ` Alex Shi 2020-09-09 1:01 ` Matthew Wilcox 2020-09-09 1:01 ` Matthew Wilcox 2020-09-09 15:43 ` Alexander Duyck 2020-09-09 15:43 ` Alexander Duyck 2020-09-09 15:43 ` Alexander Duyck 2020-09-09 17:07 ` Matthew Wilcox 2020-09-09 17:07 ` Matthew Wilcox 2020-09-09 18:24 ` Hugh Dickins 2020-09-09 18:24 ` Hugh Dickins 2020-09-09 18:24 ` Hugh Dickins 2020-09-09 20:15 ` Matthew Wilcox 2020-09-09 20:15 ` Matthew Wilcox 2020-09-09 21:05 ` Hugh Dickins 2020-09-09 21:05 ` Hugh Dickins 2020-09-09 21:05 ` Hugh Dickins 2020-09-09 21:17 ` Alexander Duyck 2020-09-09 21:17 ` Alexander Duyck 2020-09-09 21:17 ` Alexander Duyck 2020-08-24 12:55 ` [PATCH v18 32/32] mm: Split release_pages work into 3 passes Alex Shi 2020-08-24 12:55 ` Alex Shi 2020-08-24 18:42 ` [PATCH v18 00/32] per memcg lru_lock Andrew Morton 2020-08-24 19:50 ` Qian Cai 2020-08-24 19:50 ` Qian Cai 2020-08-24 20:24 ` Hugh Dickins 2020-08-24 20:24 ` Hugh Dickins 2020-08-24 20:24 ` Hugh Dickins 2020-08-25 1:56 ` Daniel Jordan 2020-08-25 1:56 ` Daniel Jordan 2020-08-25 3:26 ` Alex Shi 2020-08-25 3:26 ` Alex Shi 2020-08-25 11:39 ` Matthew Wilcox 2020-08-25 11:39 ` Matthew Wilcox 2020-08-26 1:19 ` Daniel Jordan 2020-08-26 8:59 ` Alex Shi 2020-08-26 8:59 ` Alex Shi 2020-08-28 1:40 ` Daniel Jordan 2020-08-28 1:40 ` Daniel Jordan 2020-08-28 5:22 ` Alex Shi 2020-08-28 5:22 ` Alex Shi 2020-09-09 2:44 ` Aaron Lu 2020-09-09 2:44 ` Aaron Lu 2020-09-09 11:40 ` Michal Hocko 2020-08-25 8:52 ` Alex Shi 2020-08-25 8:52 ` Alex Shi 2020-08-25 13:00 ` Alex Shi 2020-08-25 13:00 ` Alex Shi 2020-08-27 7:01 ` Hugh Dickins 2020-08-27 7:01 ` Hugh Dickins 2020-08-27 12:20 ` Race between freeing and waking page Matthew Wilcox 2020-09-08 23:41 ` [PATCH v18 00/32] per memcg lru_lock: reviews Hugh Dickins 2020-09-08 23:41 ` Hugh Dickins 2020-09-09 2:24 ` Wei Yang 2020-09-09 2:24 ` Wei Yang 2020-09-09 15:08 ` Alex Shi 2020-09-09 15:08 ` Alex Shi 2020-09-09 23:16 ` Hugh Dickins 2020-09-09 23:16 ` Hugh Dickins 2020-09-11 2:50 ` Alex Shi 2020-09-11 2:50 ` Alex Shi 2020-09-12 2:13 ` Hugh Dickins 2020-09-12 2:13 ` Hugh Dickins 2020-09-13 14:21 ` Alex Shi 2020-09-13 14:21 ` Alex Shi 2020-09-15 8:21 ` Hugh Dickins 2020-09-15 8:21 ` Hugh Dickins 2020-09-15 8:21 ` Hugh Dickins 2020-09-15 16:58 ` Daniel Jordan 2020-09-15 16:58 ` Daniel Jordan 2020-09-16 12:44 ` Alex Shi 2020-09-17 2:37 ` Alex Shi 2020-09-17 2:37 ` Alex Shi 2020-09-17 14:35 ` Daniel Jordan 2020-09-17 14:35 ` Daniel Jordan 2020-09-17 15:39 ` Alexander Duyck 2020-09-17 15:39 ` Alexander Duyck 2020-09-17 15:39 ` Alexander Duyck 2020-09-17 16:48 ` Daniel Jordan 2020-09-17 16:48 ` Daniel Jordan 2020-09-12 8:38 ` Hugh Dickins 2020-09-12 8:38 ` Hugh Dickins 2020-09-12 8:38 ` Hugh Dickins 2020-09-13 14:22 ` Alex Shi [this message] 2020-09-13 14:22 ` Alex Shi 2020-09-09 16:11 ` Alexander Duyck 2020-09-09 16:11 ` Alexander Duyck 2020-09-09 16:11 ` Alexander Duyck 2020-09-10 0:32 ` Hugh Dickins 2020-09-10 0:32 ` Hugh Dickins 2020-09-10 0:32 ` Hugh Dickins 2020-09-10 14:24 ` Alexander Duyck 2020-09-10 14:24 ` Alexander Duyck 2020-09-10 14:24 ` Alexander Duyck 2020-09-12 5:12 ` Hugh Dickins 2020-09-12 5:12 ` Hugh Dickins 2020-09-12 5:12 ` Hugh Dickins 2020-08-25 7:21 ` [PATCH v18 00/32] per memcg lru_lock Michal Hocko 2020-08-25 7:21 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=2fed13c0-1d78-fa92-b607-e997b1bc5fb2@linux.alibaba.com \ --to=alex.shi@linux.alibaba.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.duyck@gmail.com \ --cc=cai@lca.pw \ --cc=cgroups@vger.kernel.org \ --cc=daniel.m.jordan@oracle.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=iamjoonsoo.kim@lge.com \ --cc=khlebnikov@yandex-team.ru \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lkp@intel.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=minchan@kernel.org \ --cc=richard.weiyang@gmail.com \ --cc=rong.a.chen@intel.com \ --cc=shakeelb@google.com \ --cc=shy828301@gmail.com \ --cc=tj@kernel.org \ --cc=vbabka@suse.cz \ --cc=vdavydov.dev@gmail.com \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.