From: Keir Fraser <keir.xen@gmail.com>
To: Simon Martin <smartin@milliways.cl>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: VCPUOP_set_periodic_timer
Date: Fri, 15 Nov 2013 13:10:14 +0000 [thread overview]
Message-ID: <CEABCDB6.3F368%keir.xen@gmail.com> (raw)
In-Reply-To: <em157111e5-fc9e-44c4-af2f-e04c1c0e967c@smartin-alien>
[-- Attachment #1.1.1: Type: text/plain, Size: 1983 bytes --]
You¹ll have to measure to confirm, but if the core is dedicated to your vcpu
then there is no reason there should be 50us jitter. Also there is not much
point playing with different schedulers if there are no other vcpus
schedulable on the cpu, the scheduler can¹t have multiple runnable vcpus to
choose between.
-- Keir
On 15/11/2013 12:37, "Simon Martin" <smartin@milliways.cl> wrote:
> Latency isn't a big problem. Jitter could be. CPU offline shouldn't be a
> problem as the system is simple and static, at power up I create 2 CPU pools,
> one for the realtime machine domU running on a single core, and one for dom0
> and a Windows machine running on the remaining cores.
>
> Any idea on the timings I can expect? For example, assuming there are no CPU
> contention issues, if I request a 125 microsecond single shot timer interrupt,
> will I get 125 microseconds +/- 5 microseconds (perfectly acceptable) or 500
> microseconds (because that is the minimum granularity) +/- 50 microseconds
> (totally unacceptable)?
>
>
> ------ Original Message ------
> From: "Keir Fraser" <keir.xen@gmail.com>
> To: "Simon Martin" <smartin@milliways.cl>; "Andrew Cooper"
> <andrew.cooper3@citrix.com>
> Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
> Sent: 15/11/2013 08:56:18
> Subject: Re: Re[2]: [Xen-devel] VCPUOP_set_periodic_timer
>
>> If you have dedicated a core to the vcpu, so you can discount scheduling
>> crosstalk, you shouldn¹t miss deadlines by more than a microsecond or two.
>> Just enough time to wake up the CPU, handle the timer interrupt, and wake up
>> the vcpu through the scheduler. There are infrequent operations that can take
>> out all CPUs for a period: taking a CPU offline for example. You could avoid
>> doing such things in your setup perhaps. Ultimately you will need to measure
>> and confirm deadline-to-notification latency distribution if it is critical
>> to you.
>>
>> -- Keir
>
[-- Attachment #1.1.2: Type: text/html, Size: 2946 bytes --]
[-- Attachment #1.2: image.png --]
[-- Type: image/png, Size: 685 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-11-15 13:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 21:18 VCPUOP_set_periodic_timer Simon Martin
2013-11-14 21:39 ` VCPUOP_set_periodic_timer Andrew Cooper
2013-11-15 11:24 ` VCPUOP_set_periodic_timer Simon Martin
2013-11-15 11:36 ` VCPUOP_set_periodic_timer Keir Fraser
2013-11-15 11:45 ` VCPUOP_set_periodic_timer Simon Martin
2013-11-15 11:56 ` VCPUOP_set_periodic_timer Keir Fraser
2013-11-15 12:37 ` VCPUOP_set_periodic_timer Simon Martin
2013-11-15 13:10 ` Keir Fraser [this message]
2013-11-15 13:13 ` VCPUOP_set_periodic_timer Andrew Cooper
2013-11-15 13:39 ` VCPUOP_set_periodic_timer Keir Fraser
2013-11-15 11:41 ` VCPUOP_set_periodic_timer Andrew Cooper
2013-11-15 12:02 ` VCPUOP_set_periodic_timer Simon Martin
2013-11-15 12:17 ` VCPUOP_set_periodic_timer Andrew Cooper
2013-11-15 12:46 ` VCPUOP_set_periodic_timer Nate Studer
2013-11-15 12:52 ` VCPUOP_set_periodic_timer Andrew Cooper
2013-11-15 12:54 ` VCPUOP_set_periodic_timer George Dunlap
2013-11-15 21:10 ` VCPUOP_set_periodic_timer Dario Faggioli
2013-11-16 20:37 ` VCPUOP_set_periodic_timer Simon Martin
2013-11-18 18:28 ` VCPUOP_set_periodic_timer Dario Faggioli
2013-11-26 14:50 ` PV guest timings Simon Martin
2013-11-26 15:11 ` Keir Fraser
2013-11-26 15:38 ` Simon Martin
2013-11-26 23:33 ` Dario Faggioli
2013-11-27 2:32 ` Simon Martin
2013-11-27 8:46 ` Dario Faggioli
2013-11-27 12:04 ` Simon Martin
2013-11-27 10:38 ` David Vrabel
2013-11-27 14:07 ` Simon Martin
2013-11-26 23:31 ` Dario Faggioli
2013-11-27 2:36 ` Simon Martin
2013-11-27 8:56 ` Dario Faggioli
2013-11-27 13:00 ` Simon Martin
2013-11-28 11:16 ` Dario Faggioli
2013-11-28 11:57 ` Simon Martin
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=CEABCDB6.3F368%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=smartin@milliways.cl \
--cc=xen-devel@lists.xen.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).