On Tue, Sep 08, 2020 at 04:41:00PM -0700, Hugh Dickins wrote: [...] >[PATCH v18 06/32] mm/thp: narrow lru locking >Why? What part does this play in the series? "narrow lru locking" can >also be described as "widen page cache locking": you are changing the >lock ordering, and not giving any reason to do so. This may be an >excellent change, or it may be a terrible change: I find that usually >lock ordering is forced upon us, and it's rare to meet an instance like >this that could go either way, and I don't know myself how to judge it. > >I do want this commit to go in, partly because it has been present in >all the testing we have done, and partly because I *can at last* see a >logical advantage to it - it also nests lru_lock inside memcg->move_lock, >allowing lock_page_memcg() to be used to stabilize page->mem_cgroup when >getting per-memcg lru_lock - though only in one place, starting in v17, >do you actually use that (and, warning: it's not used correctly there). > >I'm not very bothered by how the local_irq_disable() looks to RT: THP >seems a very bad idea in an RT kernel. Earlier I asked you to run this >past Kirill and Matthew and Johannes: you did so, thank you, and Kirill >has blessed it, and no one has nacked it, and I have not noticed any >disadvantage from this change in lock ordering (documented in 23/32), >so I'm now going to say > >Acked-by: Hugh Dickins <hughd@xxxxxxxxxx> > >But I wish you could give some reason for it in the commit message! > >Signed-off-by: Wei Yang <richard.weiyang@xxxxxxxxx> >Is that correct? Or Wei Yang suggested some part of it perhaps? > If my memory is correct, we had some offline discussion about this change. -- Wei Yang Help you, Help me
