From: Valentin Schneider <valentin.schneider@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH 3/3] irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime Date: Sun, 24 Oct 2021 16:52:10 +0100 [thread overview] Message-ID: <878ryiju8l.mognet@arm.com> (raw) In-Reply-To: <87o87gt4at.wl-maz@kernel.org> On 23/10/21 11:37, Marc Zyngier wrote: > On Fri, 22 Oct 2021 11:33:07 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: >> @@ -5234,6 +5243,11 @@ static int its_cpu_memreserve_lpi(unsigned int cpu) >> paddr = page_to_phys(pend_page); >> WARN_ON(gic_reserve_range(paddr, LPI_PENDBASE_SZ)); >> >> +out: >> + /* This only needs to run once per CPU */ >> + if (cpumask_equal(&cpus_booted_once_mask, cpu_possible_mask)) >> + schedule_work(&rdist_memreserve_cpuhp_cleanup_work); > > Which makes me wonder. Do we actually need any flag at all if all we > need to check is whether the CPU has been through the callback at > least once? I have the strong feeling that we are tracking the same > state multiple times here. > Agreed, cf. my reply on 2/3. > Also, could the cpuhp callbacks ever run concurrently? If they could, > two CPUs could schedule the cleanup work in parallel, with interesting > results. You'd need a cmpxchg on the cpuhp state in the workfn. > So I think the cpuhp callbacks may run concurrently, but at a quick glance it seems like we can't get two instances of the same work executing concurrently: schedule_work()->queue_work() doesn't re-queue a work if it's already pending, and __queue_work() checks a work's previous pool in case it might still be running there. Regardless, that's one less thing to worry about if we make the cpuhp callback body run at most once on each CPU (only a single CPU will be able to queue the removal work).
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com> To: Marc Zyngier <maz@kernel.org> Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Thomas Gleixner <tglx@linutronix.de>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Ard Biesheuvel <ardb@kernel.org> Subject: Re: [PATCH 3/3] irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime Date: Sun, 24 Oct 2021 16:52:10 +0100 [thread overview] Message-ID: <878ryiju8l.mognet@arm.com> (raw) In-Reply-To: <87o87gt4at.wl-maz@kernel.org> On 23/10/21 11:37, Marc Zyngier wrote: > On Fri, 22 Oct 2021 11:33:07 +0100, > Valentin Schneider <valentin.schneider@arm.com> wrote: >> @@ -5234,6 +5243,11 @@ static int its_cpu_memreserve_lpi(unsigned int cpu) >> paddr = page_to_phys(pend_page); >> WARN_ON(gic_reserve_range(paddr, LPI_PENDBASE_SZ)); >> >> +out: >> + /* This only needs to run once per CPU */ >> + if (cpumask_equal(&cpus_booted_once_mask, cpu_possible_mask)) >> + schedule_work(&rdist_memreserve_cpuhp_cleanup_work); > > Which makes me wonder. Do we actually need any flag at all if all we > need to check is whether the CPU has been through the callback at > least once? I have the strong feeling that we are tracking the same > state multiple times here. > Agreed, cf. my reply on 2/3. > Also, could the cpuhp callbacks ever run concurrently? If they could, > two CPUs could schedule the cleanup work in parallel, with interesting > results. You'd need a cmpxchg on the cpuhp state in the workfn. > So I think the cpuhp callbacks may run concurrently, but at a quick glance it seems like we can't get two instances of the same work executing concurrently: schedule_work()->queue_work() doesn't re-queue a work if it's already pending, and __queue_work() checks a work's previous pool in case it might still be running there. Regardless, that's one less thing to worry about if we make the cpuhp callback body run at most once on each CPU (only a single CPU will be able to queue the removal work). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-24 15:52 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-22 10:33 [PATCH 0/3] irqchip/gic-v3-its: Fix LPI pending table handling vs PREEMPT_RT Valentin Schneider 2021-10-22 10:33 ` Valentin Schneider 2021-10-22 10:33 ` [PATCH 1/3] irqchip/gic-v3-its: Give the percpu rdist struct its own flags field Valentin Schneider 2021-10-22 10:33 ` Valentin Schneider 2021-10-23 9:10 ` Marc Zyngier 2021-10-23 9:10 ` Marc Zyngier 2021-10-24 15:50 ` Valentin Schneider 2021-10-24 15:50 ` Valentin Schneider 2021-10-22 10:33 ` [PATCH 2/3] irqchip/gic-v3-its: Postpone LPI pending table freeing and memreserve Valentin Schneider 2021-10-22 10:33 ` Valentin Schneider 2021-10-23 9:48 ` Marc Zyngier 2021-10-23 9:48 ` Marc Zyngier 2021-10-24 15:51 ` Valentin Schneider 2021-10-24 15:51 ` Valentin Schneider 2021-10-25 11:57 ` Marc Zyngier 2021-10-25 11:57 ` Marc Zyngier 2021-10-22 10:33 ` [PATCH 3/3] irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime Valentin Schneider 2021-10-22 10:33 ` Valentin Schneider 2021-10-23 10:37 ` Marc Zyngier 2021-10-23 10:37 ` Marc Zyngier 2021-10-24 15:52 ` Valentin Schneider [this message] 2021-10-24 15:52 ` Valentin Schneider
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=878ryiju8l.mognet@arm.com \ --to=valentin.schneider@arm.com \ --cc=ardb@kernel.org \ --cc=bigeasy@linutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rt-users@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=tglx@linutronix.de \ --cc=will@kernel.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.