From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: "Cédric Le Goater" <clg@kaod.org>,
qemu-ppc@nongnu.org, "Greg Kurz" <groug@kaod.org>,
"Nicholas Piggin" <npiggin@gmail.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH] Implement qemu_thread_yield for posix, use it in mttcg to handle EXCP_YIELD
Date: Fri, 20 Dec 2019 13:11:45 +0000 [thread overview]
Message-ID: <87h81vdtv2.fsf@linaro.org> (raw)
In-Reply-To: <20190717054655.14104-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> This is a bit of proof of concept in case mttcg becomes more important
> yield could be handled like this. You can have by accident or deliberately
> force vCPUs onto the same physical CPU and cause inversion issues when the
> lock holder was preempted by the waiter. This is lightly tested but not
> to the point of measuring performance difference.
Sorry I'm so late replying.
Really this comes down to what EXCP_YIELD semantics are meant to mean.
For ARM it's a hint operation because we also have WFE which should halt
until there is some sort of change of state. In those cases exiting the
main-loop and sitting in wait_for_io should be the correct response. If
a vCPU is suspended waiting on the halt condition doesn't it have the
same effect?
>
> I really consider the previous confer/prod patches more important just to
> provide a more complete guest environment and better test coverage, than
> performance, but maybe someone wants to persue this.
>
> Thanks,
> Nick
> ---
> cpus.c | 6 ++++++
> hw/ppc/spapr_hcall.c | 14 +++++++-------
> include/qemu/thread.h | 1 +
> util/qemu-thread-posix.c | 5 +++++
> util/qemu-thread-win32.c | 4 ++++
> 5 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/cpus.c b/cpus.c
> index 927a00aa90..f036e062d9 100644
> --- a/cpus.c
> +++ b/cpus.c
> @@ -1760,6 +1760,12 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
> qemu_mutex_unlock_iothread();
> cpu_exec_step_atomic(cpu);
> qemu_mutex_lock_iothread();
> + break;
> + case EXCP_YIELD:
> + qemu_mutex_unlock_iothread();
> + qemu_thread_yield();
> + qemu_mutex_lock_iothread();
> + break;
> default:
> /* Ignore everything else? */
> break;
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 57c1ee0fe1..9c24a64dfe 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1162,13 +1162,13 @@ static target_ulong h_confer(PowerPCCPU *cpu, SpaprMachineState *spapr,
> return H_SUCCESS;
> }
>
> - /*
> - * The targeted confer does not do anything special beyond yielding
> - * the current vCPU, but even this should be better than nothing.
> - * At least for single-threaded tcg, it gives the target a chance to
> - * run before we run again. Multi-threaded tcg does not really do
> - * anything with EXCP_YIELD yet.
> - */
> + /*
> + * The targeted confer does not do anything special beyond yielding
> + * the current vCPU, but even this should be better than nothing.
> + * For single-threaded tcg, it gives the target a chance to run
> + * before we run again, multi-threaded tcg will yield the CPU to
> + * another vCPU.
> + */
> }
>
> cs->exception_index = EXCP_YIELD;
> diff --git a/include/qemu/thread.h b/include/qemu/thread.h
> index 55d83a907c..8525b0a70a 100644
> --- a/include/qemu/thread.h
> +++ b/include/qemu/thread.h
> @@ -160,6 +160,7 @@ void qemu_thread_get_self(QemuThread *thread);
> bool qemu_thread_is_self(QemuThread *thread);
> void qemu_thread_exit(void *retval);
> void qemu_thread_naming(bool enable);
> +void qemu_thread_yield(void);
>
> struct Notifier;
> /**
> diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
> index 1bf5e65dea..91b12a1082 100644
> --- a/util/qemu-thread-posix.c
> +++ b/util/qemu-thread-posix.c
> @@ -573,3 +573,8 @@ void *qemu_thread_join(QemuThread *thread)
> }
> return ret;
> }
> +
> +void qemu_thread_yield(void)
> +{
> + pthread_yield();
> +}
> diff --git a/util/qemu-thread-win32.c b/util/qemu-thread-win32.c
> index 572f88535d..72fe406bef 100644
> --- a/util/qemu-thread-win32.c
> +++ b/util/qemu-thread-win32.c
> @@ -442,3 +442,7 @@ bool qemu_thread_is_self(QemuThread *thread)
> {
> return GetCurrentThreadId() == thread->tid;
> }
> +
> +void qemu_thread_yield(void)
> +{
> +}
--
Alex Bennée
next prev parent reply other threads:[~2019-12-20 13:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 5:46 [Qemu-devel] [RFC PATCH] Implement qemu_thread_yield for posix, use it in mttcg to handle EXCP_YIELD Nicholas Piggin
2019-07-17 11:48 ` David Gibson
2019-12-20 13:11 ` Alex Bennée [this message]
2020-01-21 11:20 ` Nicholas Piggin
2020-01-21 14:37 ` Alex Bennée
2020-01-22 3:26 ` David Gibson
2020-01-22 18:01 ` Richard Henderson
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=87h81vdtv2.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=clg@kaod.org \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 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.