* Re: [RFC PATCH 00/13] x86 User Interrupts support
[not found] ` <778d40fe-ad8e-fd7c-4caa-499910bb0925@intel.com>
@ 2021-10-01 16:35 ` Stefan Hajnoczi
2021-10-01 16:41 ` Richard Henderson
0 siblings, 1 reply; 2+ messages in thread
From: Stefan Hajnoczi @ 2021-10-01 16:35 UTC (permalink / raw)
To: Sohil Mehta, Peter Maydell, Alex Bennée, Richard Henderson
Cc: Peter Zijlstra (Intel), qemu-devel, Dave Hansen, linux-kselftest,
H. Peter Anvin, Shuah Khan, Thomas Gleixner, linux-arch,
Raj Ashok, Jonathan Corbet, the arch/x86 maintainers, Ingo Molnar,
Zeng Guang, Gayatri Kammela, Shankar, Ravi V, Jacob Pan,
Arnd Bergmann, Ramesh Thomas, Borislav Petkov, Andy Lutomirski,
Williams, Dan J, Christian Brauner, Jens Axboe, Tony Luck,
Linux API, Randy E Witt, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]
On Thu, Sep 30, 2021 at 10:24:24AM -0700, Sohil Mehta wrote:
>
> On 9/30/2021 9:30 AM, Stefan Hajnoczi wrote:
> > On Tue, Sep 28, 2021 at 09:31:34PM -0700, Andy Lutomirski wrote:
> > >
> > > I spent some time reviewing the docs (ISE) and contemplating how this all fits together, and I have a high level question:
> > >
> > > Can someone give an example of a realistic workload that would benefit from SENDUIPI and precisely how it would use SENDUIPI? Or an example of a realistic workload that would benefit from hypothetical device-initiated user interrupts and how it would use them? I'm having trouble imagining something that wouldn't work as well or better by simply polling, at least on DMA-coherent architectures like x86.
> > I was wondering the same thing. One thing came to mind:
> >
> > An application that wants to be *interrupted* from what it's doing
> > rather than waiting until the next polling point. For example,
> > applications that are CPU-intensive and have green threads. I can't name
> > a real application like this though :P.
>
> Thank you Stefan and Andy for giving this some thought.
>
> We are consolidating the information internally on where and how exactly we
> expect to see benefits with real workloads for the various sources of User
> Interrupts. It will take a few days to get back on this one.
One possible use case came to mind in QEMU's TCG just-in-time compiler:
QEMU's TCG threads execute translated code. There are events that
require interrupting these threads. Today a check is performed at the
start of every translated block. Most of the time the check is false and
it's a waste of CPU.
User interrupts can eliminate the need for checks by interrupting TCG
threads when events occur.
I don't know whether this will improve performance or how feasible it is
to implement, but I've added people who might have ideas. (For a summary
of user interrupts, see
https://lwn.net/SubscriberLink/871113/60652640e11fc5df/.)
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [RFC PATCH 00/13] x86 User Interrupts support
2021-10-01 16:35 ` [RFC PATCH 00/13] x86 User Interrupts support Stefan Hajnoczi
@ 2021-10-01 16:41 ` Richard Henderson
0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2021-10-01 16:41 UTC (permalink / raw)
To: Stefan Hajnoczi, Sohil Mehta, Peter Maydell, Alex Bennée
Cc: Peter Zijlstra (Intel), qemu-devel, Dave Hansen, linux-kselftest,
H. Peter Anvin, Shuah Khan, Thomas Gleixner, linux-arch,
Raj Ashok, Jonathan Corbet, the arch/x86 maintainers, Ingo Molnar,
Zeng Guang, Gayatri Kammela, Shankar, Ravi V, Jacob Pan,
Arnd Bergmann, Ramesh Thomas, Borislav Petkov, Andy Lutomirski,
Williams, Dan J, Christian Brauner, Jens Axboe, Tony Luck,
Linux API, Randy E Witt, Linux Kernel Mailing List
On 10/1/21 12:35 PM, Stefan Hajnoczi wrote:
> QEMU's TCG threads execute translated code. There are events that
> require interrupting these threads. Today a check is performed at the
> start of every translated block. Most of the time the check is false and
> it's a waste of CPU.
>
> User interrupts can eliminate the need for checks by interrupting TCG
> threads when events occur.
We used to use interrupts, and stopped because we need to wait until the guest is in a
stable state. The guest is always in a stable state at the beginning of each TB.
See 378df4b2375.
r~
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-10-01 16:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210913200132.3396598-1-sohil.mehta@intel.com>
[not found] ` <456bf9cf-87b8-4c3d-ac0c-7e392bcf26de@www.fastmail.com>
[not found] ` <YVXmGTo5Uzp44QQq@stefanha-x1.localdomain>
[not found] ` <778d40fe-ad8e-fd7c-4caa-499910bb0925@intel.com>
2021-10-01 16:35 ` [RFC PATCH 00/13] x86 User Interrupts support Stefan Hajnoczi
2021-10-01 16:41 ` Richard Henderson
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).