From: Nicholas Piggin <npiggin@gmail.com> To: Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org> Cc: Anton Blanchard <anton@ozlabs.org>, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Randy Dunlap <rdunlap@infradead.org> Subject: Re: [PATCH v3 0/4] shoot lazy tlbs Date: Sat, 05 Jun 2021 10:17:50 +1000 [thread overview] Message-ID: <1622851909.wxi3vcx3m8.astroid@bobo.none> (raw) In-Reply-To: <991660c3-c2bf-c303-a55c-7454f0cc45f7@kernel.org> 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, or someone, needs to dust off my membarrier series before any of > these kinds of changes get made. The barrier situation in the scheduler > is too confusing otherwise. > I disagree, I've disentangled the changes from membarrier stuff now, they can be done concurrently. Thanks, Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com> To: Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org> Cc: linux-arch@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 0/4] shoot lazy tlbs Date: Sat, 05 Jun 2021 10:17:50 +1000 [thread overview] Message-ID: <1622851909.wxi3vcx3m8.astroid@bobo.none> (raw) In-Reply-To: <991660c3-c2bf-c303-a55c-7454f0cc45f7@kernel.org> 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, or someone, needs to dust off my membarrier series before any of > these kinds of changes get made. The barrier situation in the scheduler > is too confusing otherwise. > I disagree, I've disentangled the changes from membarrier stuff now, they can be done concurrently. Thanks, Nick
next prev parent reply other threads:[~2021-06-05 0:19 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-01 6:22 [PATCH v3 0/4] shoot lazy tlbs Nicholas Piggin 2021-06-01 6:22 ` Nicholas Piggin 2021-06-01 6:23 ` [PATCH v3 1/4] lazy tlb: introduce lazy mm refcount helper functions Nicholas Piggin 2021-06-01 6:23 ` Nicholas Piggin 2021-06-01 6:23 ` [PATCH v3 2/4] lazy tlb: allow lazy tlb mm switching to be configurable Nicholas Piggin 2021-06-01 6:23 ` Nicholas Piggin 2021-06-01 6:23 ` [PATCH v3 3/4] lazy tlb: shoot lazies, a non-refcounting lazy tlb option Nicholas Piggin 2021-06-01 6:23 ` Nicholas Piggin 2021-06-01 6:23 ` [PATCH v3 4/4] powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN Nicholas Piggin 2021-06-01 6:23 ` Nicholas Piggin 2021-06-04 16:54 ` [PATCH v3 0/4] shoot lazy tlbs Andy Lutomirski 2021-06-04 16:54 ` Andy Lutomirski 2021-06-04 17:05 ` Andy Lutomirski 2021-06-04 17:05 ` Andy Lutomirski 2021-06-05 0:17 ` Nicholas Piggin [this message] 2021-06-05 0:17 ` Nicholas Piggin 2021-06-05 0:26 ` Nicholas Piggin 2021-06-05 0:26 ` Nicholas Piggin 2021-06-05 2:52 ` Nicholas Piggin 2021-06-05 2:52 ` Nicholas Piggin
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=1622851909.wxi3vcx3m8.astroid@bobo.none \ --to=npiggin@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=anton@ozlabs.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=luto@kernel.org \ --cc=rdunlap@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.