qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff


From: Alex Bligh
Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff
Date: Mon, 22 Jul 2013 10:40:14 +0100

Liu,

--On 22 July 2013 12:38:02 +0800 liu ping fan <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]