From: Marc Zyngier <firstname.lastname@example.org> To: Jingyi Wang <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test Date: Mon, 17 Aug 2020 09:26:19 +0100 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 2020-08-17 02:46, Jingyi Wang wrote: > On 8/11/2020 3:49 PM, Marc Zyngier wrote: >> On 2020-08-11 02:48, Jingyi Wang wrote: [...] >>> As I mentioned before, we want to add vLPI direct injection test >>> in KUT, meanwhile measure the latency of hardware vLPI injection. >>> >>> Sure, vLPI is triggered by hardware. Since kernel supports sending >>> ITS INT command in guest to trigger vLPI, I wonder if it is possible >> >> So can the host. >> >>> to add an extra interface to make a vLPI hardware-offload(just as >>> kvm_vgic_v4_set_forwarding() does). If so, vgic_its_trigger_msi() >>> can inject vLPI directly instead of using LR. >> >> The interface exists, it is in debugfs. But it mandates that the >> device exists. And no, I am not willing to add an extra KVM userspace >> API for this. >> >> The whole concept of injecting an INT to measure the performance >> of GICv4 is slightly bonkers, actually. Most of the cost is paid >> on the injection path (queuing a pair of command, waiting until >> the ITS wakes up and generate the signal...). >> >> What you really want to measure is the time from generation of >> the LPI by a device until the guest acknowledges the interrupt >> to the device itself. and this can only be implemented in the >> device. >> >> M. > > OK understood. I just thought measuring the latency of the path > kvm->guest can be useful. That's the problem. There is no way you can implement this, because you cannot distinguish injection latency from the delivery latency. And frankly, it doesn't matter, because the hypervisor is not on that path at all (if it is slow, that's because the HW is slow, and you can't change anything in KVM to make it better). On the other hand, measuring the latency of a guest being scheduled back in when blocked on WFI would be much more relevant, as this is exactly what would happen on delivery of a doorbell. M. -- Jazz is not dead. It just smells funny...
prev parent reply index Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-31 7:42 Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 01/10] arm64: microbench: get correct ipi received num Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 02/10] arm64: microbench: Generalize ipi test names Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 03/10] arm64: microbench: gic: Add ipi latency test for gicv4.1 support kvm Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 04/10] arm64: its: Handle its command queue wrapping Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 05/10] arm64: microbench: its: Add LPI latency test Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 06/10] arm64: microbench: Allow each test to specify its running times Jingyi Wang 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 07/10] arm64: microbench: Add time limit for each individual test Jingyi Wang 2020-08-01 16:13 ` Andrew Jones 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 08/10] arm64: microbench: Add vtimer latency test Jingyi Wang 2020-08-01 16:22 ` Andrew Jones 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 09/10] arm64: microbench: Add test->post() to further process test results Jingyi Wang 2020-08-01 17:03 ` Andrew Jones 2020-07-31 7:42 ` [kvm-unit-tests PATCH v3 10/10] arm64: microbench: Add timer_post() to get actual PPI latency Jingyi Wang 2020-07-31 12:01 ` [kvm-unit-tests PATCH v3 00/10] arm/arm64: Add IPI/LPI/vtimer latency test Andrew Jones 2020-08-03 2:15 ` Jingyi Wang 2020-08-01 17:40 ` Andrew Jones 2020-08-05 11:54 ` Jingyi Wang 2020-08-05 12:13 ` Marc Zyngier 2020-08-11 1:48 ` Jingyi Wang 2020-08-11 7:49 ` Marc Zyngier 2020-08-17 1:46 ` Jingyi Wang 2020-08-17 8:26 ` Marc Zyngier [this message]
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
KVM Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \ email@example.com public-inbox-index kvm Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.kvm AGPL code for this site: git clone https://public-inbox.org/public-inbox.git