All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  parent reply	other threads:[~2020-08-17  7:56 UTC|newest]

Thread overview: 13+ 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  6:04   ` kernel test robot
2020-08-17  6:04     ` kernel test robot
2020-08-17  7:55   ` peterz [this message]
2020-08-21 15:32   ` kernel test robot
2020-08-21 15:32     ` kernel test robot
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 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.