From: Alex Bligh <alex@alex.org.uk>
To: liu ping fan <qemulist@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Alex Bligh <alex@alex.org.uk>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
Date: Mon, 22 Jul 2013 10:40:14 +0100 [thread overview]
Message-ID: <628DFBF37B094813C72B6DBF@Ximines.local> (raw)
In-Reply-To: <CAJnKYQm8r3eg3B7PBU_siqrP_hSFtWcKazaKJt0b8qwcMWxiqw@mail.gmail.com>
Liu,
--On 22 July 2013 12:38:02 +0800 liu ping fan <qemulist@gmail.com> wrote:
> I read your second series, and try to summary the main different between
> us. Please correct me, if I misunderstood something.
> --1st. You try to create a separate QemuClock for AioContext.
> I think QemuClock is the clock event source and we have three
> classic with fine definition. They should be qemu-wide for time
> measurement. On the other handler, timer is a concept for timeout,
> so it can be AioContext-related. So I have patch2&5.
Yes and no. QEMUClock is not a clock source. QEMUClock /has/ a clock
source, and more than one QEMUClock can share the same clock source.
QEMUClock does have its own list of timers, and so if you only
want to run a subset of timers in aio_poll (which is I believe the
requirement so not to change the behaviour of existing timers),
you need a separate QEMUClock.
The approach I took (StefanH's idea) was to put a QEMUClock into
each AioContext. Arguably you might want to put a set of 3 QEMUClock's
into each AioContext, one for each clock source.
QEMUClock itself is very lightweight as far as I can tell.
> --2nd. You want to substitute alarm_timer with timeout of poll.
Correct.
> I try to trigger each specified thread when its deadline comes.
> But unfortunately, the signal can not be delivered to the specified
> thread directly, and I need timerfd for each AioContext. (If we can
> have the equivalent on other platform)
Firstly, I can't see the advantage of keeping the alarm_timer stuff around
at all if we can delete it. Save, of course, that on systems that don't
have ppoll or equivalent you lose sub-millisecond timing by deleting them.
Secondly, I don't understand this point. Let's assume we keep alarm_timers.
The timers run from signals at the moment (under POSIX) and could easily
run in their own thread. They synchronise with the thread waiting on poll
by using the event notifiers. Why do you need to have multiple threads
dealing with timers? At most one new thread (and quite possibly zero)
should be sufficient, as all they need to do is write() to the correct
notifier FD, which will end the relevant poll. Of course if we delete
alarm_timers this is all irrelevant.
--
Alex Bligh
next prev parent reply other threads:[~2013-07-22 9:40 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-21 8:42 [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff Liu Ping Fan
2013-07-21 8:42 ` [Qemu-devel] [RFC 1/8] timer: associate alarm_timer with AioContext Liu Ping Fan
2013-07-22 6:55 ` Jan Kiszka
2013-07-21 8:42 ` [Qemu-devel] [RFC 2/8] timer: pick out timer list info from QemuClock Liu Ping Fan
2013-07-21 8:43 ` [Qemu-devel] [RFC 3/8] timer: make timers_state static Liu Ping Fan
2013-07-22 6:36 ` Jan Kiszka
2013-07-22 17:40 ` [Qemu-devel] [Qemu-trivial] " Michael Tokarev
2013-07-21 8:43 ` [Qemu-devel] [RFC 4/8] timer: protect timers_state with lock Liu Ping Fan
2013-07-22 6:40 ` Jan Kiszka
2013-07-21 8:43 ` [Qemu-devel] [RFC 5/8] timer: associate timer with AioContext Liu Ping Fan
2013-07-21 8:43 ` [Qemu-devel] [RFC 6/8] timer: run timers on aio_poll Liu Ping Fan
2013-07-21 9:55 ` Alex Bligh
2013-07-23 2:56 ` liu ping fan
2013-07-23 14:22 ` Alex Bligh
2013-07-21 8:43 ` [Qemu-devel] [RFC 7/8] block: associate BlockDriverState with AioContext Liu Ping Fan
2013-07-21 8:43 ` [Qemu-devel] [RFC 8/8] block: enable throttle with aiocontext Liu Ping Fan
2013-07-21 9:53 ` [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff Alex Bligh
2013-07-22 4:38 ` liu ping fan
2013-07-22 6:28 ` Jan Kiszka
2013-07-23 2:51 ` liu ping fan
2013-07-25 11:44 ` Stefan Hajnoczi
2013-07-25 12:01 ` Jan Kiszka
2013-07-22 9:40 ` Alex Bligh [this message]
2013-07-22 10:18 ` liu ping fan
2013-07-23 2:53 ` liu ping fan
2013-07-23 10:30 ` Paolo Bonzini
2013-07-24 1:28 ` liu ping fan
2013-07-24 6:42 ` Paolo Bonzini
2013-07-24 7:31 ` Alex Bligh
2013-07-24 7:43 ` Paolo Bonzini
2013-07-24 8:01 ` Alex Bligh
2013-07-24 8:19 ` Paolo Bonzini
2013-07-24 8:37 ` Alex Bligh
2013-07-24 11:28 ` Paolo Bonzini
2013-07-24 8:30 ` liu ping fan
2013-07-24 7:43 ` liu ping fan
2013-07-24 7:54 ` Paolo Bonzini
2013-07-24 8:06 ` Alex Bligh
2013-07-24 14:46 ` [Qemu-devel] [PATCHv2a] [RFC 8/7 (really)] Add prctl(PR_SET_TIMERSLACK, 1, ...) to reduce timer slack Alex Bligh
2013-07-23 14:21 ` [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff Alex Bligh
2013-07-25 11:47 ` Stefan Hajnoczi
2013-07-25 12:05 ` Stefan Hajnoczi
2013-07-25 12:21 ` Alex Bligh
2013-07-25 12:32 ` Jan Kiszka
2013-07-25 12:35 ` Paolo Bonzini
2013-07-25 12:38 ` Jan Kiszka
2013-07-25 12:41 ` Stefan Hajnoczi
2013-07-25 12:48 ` Jan Kiszka
2013-07-25 13:02 ` Paolo Bonzini
2013-07-25 13:06 ` Jan Kiszka
2013-07-25 13:31 ` Stefan Hajnoczi
2013-07-25 14:01 ` Jan Kiszka
2013-07-25 12:59 ` Paolo Bonzini
2013-07-25 18:53 ` Alex Bligh
2013-07-26 8:43 ` Stefan Hajnoczi
2013-07-26 9:08 ` Alex Bligh
2013-07-26 9:19 ` Paolo Bonzini
2013-07-29 8:58 ` Kevin Wolf
2013-07-29 10:22 ` Alex Bligh
2013-07-29 10:45 ` Paolo Bonzini
2013-07-31 9:02 ` Stefan Hajnoczi
2013-07-26 10:05 ` Jan Kiszka
2013-07-26 19:29 ` Alex Bligh
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=628DFBF37B094813C72B6DBF@Ximines.local \
--to=alex@alex.org.uk \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=stefanha@redhat.com \
/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).