From: peterz@infradead.org
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: linux-mips@vger.kernel.org,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Huacai Chen" <chenhc@lemote.com>,
"Aleksandar Markovic" <aleksandar.qemu.devel@gmail.com>,
"Paul Burton" <paulburton@kernel.org>,
"Serge Semin" <Sergey.Semin@baikalelectronics.ru>,
"WANG Xuerui" <git@xen0n.name>, 周琰杰 <zhouyanjie@wanyeetech.com>,
"Liangliang Huang" <huanglllzu@gmail.com>,
"afzal mohammed" <afzal.mohd.ma@gmail.com>,
"Ingo Molnar" <mingo@kernel.org>, "Peter Xu" <peterx@redhat.com>,
"Sergey Korolev" <s.korolev@ndmsystems.com>,
"Alexey Malahov" <Alexey.Malahov@baikalelectronics.ru>,
"Marc Zyngier" <maz@kernel.org>,
"Anup Patel" <anup.patel@wdc.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Atish Patra" <atish.patra@wdc.com>,
"Michael Kelley" <mikelley@microsoft.com>,
"Steven Price" <steven.price@arm.com>,
"Daniel Jordan" <daniel.m.jordan@oracle.com>,
"Ming Lei" <ming.lei@redhat.com>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/7] MIPS: sync-r4k: Rework to be many cores firendly
Date: Mon, 17 Aug 2020 09:55:33 +0200 [thread overview]
Message-ID: <20200817075533.GI2674@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200817034701.3515721-2-jiaxun.yang@flygoat.com>
On Mon, Aug 17, 2020 at 11:46:40AM +0800, Jiaxun Yang wrote:
> Here we reworked the whole procdure. Now the synchronise event on CPU0
> is triggered by smp call function, and we won't touch the count on CPU0
> at all.
Are you telling me, that in 2020 you're building chips that need
horrible crap like this ?!?
> +#define MAX_LOOPS 1000
> +
> +void synchronise_count_master(void *unused)
> {
> unsigned long flags;
> + long delta;
> + int i;
>
> + if (atomic_read(&sync_stage) != STAGE_START)
> + BUG();
BUG_ON(atomic_read(&sync_state) != STAGE_START);
>
> local_irq_save(flags);
That's silly, replace with: lockdep_assert_hardirqs_disabled().
>
> + cur_count = read_c0_count();
> + smp_wmb();
> + atomic_inc(&sync_stage); /* inc to STAGE_MASTER_READY */
memory barriers require a comment that describes the ordering. This
includes at least 2 variables and at least 2 code paths (*) -- afaict
your code does NOT have a matching barrier, see below.
>
> + for (i = 0; i < MAX_LOOPS; i++) {
> + cur_count = read_c0_count();
> smp_wmb();
> - atomic_inc(&count_count_stop);
> + if (atomic_read(&sync_stage) == STAGE_SLAVE_SYNCED)
> + break;
> }
> +
> + delta = read_c0_count() - fini_count;
>
> local_irq_restore(flags);
>
> + if (i == MAX_LOOPS)
> + pr_err("sync-r4k: Master: synchronise timeout\n");
> + else
> + pr_info("sync-r4k: Master: synchronise succeed, maximum delta: %ld\n", delta);
> +
> + return;
> }
>
> void synchronise_count_slave(int cpu)
> {
> int i;
> unsigned long flags;
> + call_single_data_t csd;
>
> + raw_spin_lock(&sync_r4k_lock);
Why should this be a raw_spnilock_t ?
>
> + /* Let variables get attention from cache */
> + for (i = 0; i < MAX_LOOPS; i++) {
> + cur_count++;
> + fini_count += cur_count;
> + cur_count += fini_count;
> }
What does this actually do? You're going to bounce those variables
between this CPU and CPU-0.
> +
> + atomic_set(&sync_stage, STAGE_START);
> + csd.func = synchronise_count_master;
> +
> + /* Master count is always CPU0 */
> + if (smp_call_function_single_async(0, &csd)) {
This is diguisting.
It also requires a comment on how the on-stack csd is correct (it is,
but it really needs a comment).
> + pr_err("sync-r4k: Salve: Failed to call master\n");
> + raw_spin_unlock(&sync_r4k_lock);
> + return;
> + }
> +
> + local_irq_save(flags);
> +
> + /* Wait until master ready */
> + while (atomic_read(&sync_stage) != STAGE_MASTER_READY)
> + cpu_relax();
This really wants to be:
atomic_cond_read_acquire(&&sync_stage, VAL == STAGE_MASTER_READY);
Because, afaict the smp_wmb() (*) in synchronize_count_master() order
against this here and we need to guarantee we read @sync_stage _before_
@cur_count.
> +
> + write_c0_count(cur_count);
> + fini_count = read_c0_count();
> + smp_wmb();
> + atomic_inc(&sync_stage); /* inc to STAGE_SLAVE_SYNCED */
>
> local_irq_restore(flags);
> +
> + raw_spin_unlock(&sync_r4k_lock);
> }
Furthermore, afaict there isn't actually any concurrency on @sync_stage,
so atomic_t isn't required, Using smp_store_release() to change state
might be far more natural.
next prev parent reply other threads:[~2020-08-17 7:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 3:46 [PATCH 0/7] R4000 clock enhancements for Loongson Jiaxun Yang
2020-08-17 3:46 ` [PATCH 1/7] MIPS: sync-r4k: Rework to be many cores firendly Jiaxun Yang
2020-08-17 7:55 ` peterz [this message]
2020-08-17 3:46 ` [PATCH 2/7] MIPS: time: Use CPUHUP to handle r4k timer Jiaxun Yang
2020-08-17 3:46 ` [PATCH 3/7] MIPS: Kconfig: Always select SYNC_R4K if both SMP and r4k timer is enabled Jiaxun Yang
2020-08-17 3:46 ` [PATCH 4/7] MIPS: Loongson64: Remove custom count sync procudure Jiaxun Yang
2020-08-17 3:46 ` [PATCH 5/7] MIPS: cevt-r4k: Don't handle IRQ if clockevent is not enabled Jiaxun Yang
2020-08-17 3:46 ` [PATCH 6/7] MIPS: cevt-r4k: Enable intimer for Loongson CPUs with extimer Jiaxun Yang
2020-08-17 3:46 ` [PATCH 7/7] MIPS: KVM: Don't use htimer when INTIMER is disabled Jiaxun Yang
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=20200817075533.GI2674@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Alexey.Malahov@baikalelectronics.ru \
--cc=Sergey.Semin@baikalelectronics.ru \
--cc=afzal.mohd.ma@gmail.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=anup.patel@wdc.com \
--cc=atish.patra@wdc.com \
--cc=chenhc@lemote.com \
--cc=daniel.m.jordan@oracle.com \
--cc=git@xen0n.name \
--cc=huanglllzu@gmail.com \
--cc=jiaxun.yang@flygoat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mike.leach@linaro.org \
--cc=mikelley@microsoft.com \
--cc=ming.lei@redhat.com \
--cc=mingo@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paulburton@kernel.org \
--cc=peterx@redhat.com \
--cc=s.korolev@ndmsystems.com \
--cc=steven.price@arm.com \
--cc=tsbogend@alpha.franken.de \
--cc=ulf.hansson@linaro.org \
--cc=zhouyanjie@wanyeetech.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®