From: Greg KH <gregkh@linuxfoundation.org>
To: Zhongqiu Han <quic_zhonhan@quicinc.com>
Cc: jirislaby@kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH] tty: mips_ejtag_fdc: Call cpu_relax() in registers polling busy loops
Date: Fri, 20 Dec 2024 16:06:44 +0100 [thread overview]
Message-ID: <2024122019-blame-multitask-8d83@gregkh> (raw)
In-Reply-To: <edfed594-a22a-4cd1-90d2-2b9f9f878f73@quicinc.com>
On Fri, Dec 20, 2024 at 09:46:27PM +0800, Zhongqiu Han wrote:
> On 12/19/2024 9:28 PM, Greg KH wrote:
> > On Thu, Dec 19, 2024 at 08:42:54PM +0800, Zhongqiu Han wrote:
> > > It is considered good practice to call cpu_relax() in busy loops, see
> > > Documentation/process/volatile-considered-harmful.rst. This can lower CPU
> > > power consumption or yield to a hyperthreaded twin processor, or serve as
> > > a compiler barrier. In addition, if something goes wrong in the busy loop
> > > at least it can prevent things from getting worse.
> > >
> > > Signed-off-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
> > > ---
> > > drivers/tty/mips_ejtag_fdc.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/tty/mips_ejtag_fdc.c b/drivers/tty/mips_ejtag_fdc.c
> > > index afbf7738c7c4..b17ead1e9698 100644
> > > --- a/drivers/tty/mips_ejtag_fdc.c
> > > +++ b/drivers/tty/mips_ejtag_fdc.c
> > > @@ -346,7 +346,7 @@ static void mips_ejtag_fdc_console_write(struct console *c, const char *s,
> > > /* Busy wait until there's space in fifo */
> > > while (__raw_readl(regs + REG_FDSTAT) & REG_FDSTAT_TXF)
> > > - ;
> > > + cpu_relax();
> > > __raw_writel(word.word, regs + REG_FDTX(c->index));
> > > }
> > > out:
> > > @@ -1233,7 +1233,7 @@ static void kgdbfdc_push_one(void)
> > > /* Busy wait until there's space in fifo */
> > > while (__raw_readl(regs + REG_FDSTAT) & REG_FDSTAT_TXF)
> > > - ;
> > > + cpu_relax();
> >
> > How did you test this? Are you _sure_ it is needed at all? I think you
> > just made these loops take a lot longer than before :(
> >
> > Have you had problems with these tight loops doing anything bad to your
> > system?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
> Thanks a lot for the review~
>
> Perhaps I should submit an RFC patch and explain the situation, as I
> don't have a MIPS device for testing. Indeed, the cpu_relax()
> implementation for MIPS is a memory barrier, which, compared to busy
> waiting, doesn't save power and can make loops slower than before.
> However, according to its definition file, for certain MIPS-based
> architectures like Loongarch-3, it can help force the Loongson-3 SFB
> (Store-Fill-Buffer) flush to avoid pending writes. Below is the
> implementation of cpu_relax() for the MIPS architecture and its
> comments.
>
> -----------------------------------------------------------------
> arch/mips/include/asm/vdso/processor.h
>
> #ifdef CONFIG_CPU_LOONGSON64
> /*
> * Loongson-3's SFB (Store-Fill-Buffer) may buffer writes indefinitely
> * when a tight read loop is executed, because reads take priority over
> * writes & the hardware (incorrectly) doesn't ensure that writes will
> * eventually occur.
> *
> * Since spin loops of any kind should have a cpu_relax() in them, force
> * an SFB flush from cpu_relax() such that any pending writes will
> * become visible as expected.
> */
> #define cpu_relax() smp_mb()
> #else
> #define cpu_relax() barrier()
> #endif
> ----------------------------------------------------------------
>
> Based on this, cpu_relax() should be needed here? :)
I don't know, please test and let us know!
Without testing of this on real hardware, we can't take this change for
obvious reasons.
thanks,
greg k-h
next prev parent reply other threads:[~2024-12-20 15:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 12:42 [PATCH] tty: mips_ejtag_fdc: Call cpu_relax() in registers polling busy loops Zhongqiu Han
2024-12-19 13:28 ` Greg KH
2024-12-20 13:46 ` Zhongqiu Han
2024-12-20 15:06 ` Greg KH [this message]
2024-12-26 13:38 ` Zhongqiu Han
2024-12-20 7:16 ` Jiri Slaby
2024-12-20 14:37 ` Zhongqiu Han
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=2024122019-blame-multitask-8d83@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=quic_zhonhan@quicinc.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.