Excerpts from Nicholas Piggin's message of June 5, 2021 10:26 am: > Excerpts from Nicholas Piggin's message of June 5, 2021 10:17 am: >> Excerpts from Andy Lutomirski's message of June 5, 2021 3:05 am: >>> On 6/4/21 9:54 AM, Andy Lutomirski wrote: >>>> On 5/31/21 11:22 PM, Nicholas Piggin wrote: >>>>> There haven't been objections to the series since last posting, this >>>>> is just a rebase and tidies up a few comments minor patch rearranging. >>>>> >>>> >>>> I continue to object to having too many modes. I like my more generic >>>> improvements better. Let me try to find some time to email again. >>>> >>> >>> Specifically, this: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/mm >> >> That's worse than what powerpc does with the shoot lazies code so >> we wouldn't use it anyway. >> >> The fact is mm-cpumask and lazy mm is very architecture specific, so I >> don't really see that another "mode" is such a problem, it's for the >> most part "this is what powerpc does" -> "this is what powerpc does". >> The only mode in the context switch is just "take a ref on the lazy mm" >> or "don't take a ref". Surely that's not too onerous to add!? >> >> Actually the bigger part of it is actually the no-lazy mmu mode which >> is not yet used, I thought it was a neat little demonstrator of how code >> works with/without lazy but I will get rid of that for submission. > > I admit that does add a bit more churn than necessary maybe that was > the main objection. > > Here is the entire kernel/sched/core.c change after that is removed. > Pretty simple now. I'll resubmit.
If it gives you some concerns about a great complex new mode, I'll put it a different way -- all this allows is the arch to say that it does not use lazy tlb mms beyond their refcounted lifetime, so there is no need to refcount the lazy tlb reference. That's all it is. One implementation of that is shoot lazies, and that could be done entirely in arch/powerpc via destroy_context (I just put it in mm/ in case it is useful to others, but that's no real difference). So you see it's really just about management of lazies, the refcounting is just a bit on the side. And lazy management is highly arch specific, x86 being one of the really different complex ones there including very complex and unique interactions with membarrier ordering, so that can't be a fair objection. Thanks, Nick
