linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] arm64/sve: Make kernel FPU protection RT friendly
Date: Thu, 29 Jul 2021 17:32:27 +0100	[thread overview]
Message-ID: <20210729163227.GR1724@arm.com> (raw)
In-Reply-To: <20210729160756.s6kvhvbdy2erqeq7@linutronix.de>

On Thu, Jul 29, 2021 at 06:07:56PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-07-29 18:00:31 [+0200], To Dave Martin wrote:
> > 
> > But I get what you mean. I'm just not sure regarding the naming since
> > the code behaves the same on x86 and arm64 here.
> 
> Assuming that everyone follows this pattern what about
>   fpregs_lock()
>   fpregs_unlock()

I'm not sure about the "fpregs".  This is really about CPU-local
resources that are contended between softirq and task context.

Some arches might not to use fp in softirq context and then their fp
regs wouldn't need this; others might have other resources that aren't
"fp" regs, but are contended in the same way.


My "local_bh" was meaning purely softirqs running on this CPU.  This was
the original meaning of "local" in this API IIUC.  This is one reason
why they must disable preemption: "local" is meaningless if preemption
is enabled, since otherwise we might randomly migrate between CPUs.

I guess the "local" was preserved in the naming on PREEMPT_RT to reduce
the amount of noise that would have resulted from a treewide rename, but
this word seems confusing if there is no CPU-localness involved.


In this particular case, we really do want to bind ourselves onto the
current CPU and disable softirqs on this CPU -- if they continue to run
elsewhere, that's just fine.

What do you think about:

get_bh_cpu_context()
put_bh_cpu_context()

or something along those lines?

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-29 16:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 10:52 arm64/sve: Two PREEMPT_RT related arm64 fixes Sebastian Andrzej Siewior
2021-07-29 10:52 ` [PATCH] arm64/sve: Delay freeing memory in fpsimd_flush_thread() Sebastian Andrzej Siewior
2021-07-29 13:58   ` Dave Martin
2021-07-29 14:26   ` Mark Brown
2021-07-29 14:39     ` Sebastian Andrzej Siewior
2021-07-29 15:37       ` Dave Martin
2021-07-29 10:52 ` [PATCH] arm64/sve: Make kernel FPU protection RT friendly Sebastian Andrzej Siewior
2021-07-29 13:54   ` Dave Martin
2021-07-29 14:17     ` Sebastian Andrzej Siewior
2021-07-29 15:34       ` Dave Martin
2021-07-29 16:00         ` Sebastian Andrzej Siewior
2021-07-29 16:07           ` Sebastian Andrzej Siewior
2021-07-29 16:32             ` Dave Martin [this message]
2021-07-29 17:11               ` Sebastian Andrzej Siewior
2021-07-29 14:22   ` Mark Brown
2021-07-29 14:41     ` Sebastian Andrzej Siewior
2021-07-29 16:23       ` Mark Brown

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=20210729163227.GR1724@arm.com \
    --to=dave.martin@arm.com \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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: 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;
as well as URLs for NNTP newsgroup(s).