On 2013-07-22 06:38, liu ping fan wrote: > On Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh <a...@alex.org.uk> wrote: >> Liu, >> >> >> --On 21 July 2013 16:42:57 +0800 Liu Ping Fan <qemul...@gmail.com> wrote: >> >>> Currently, the timers run on iothread within BQL, so virtio-block >>> dataplane can not use throttle, as Stefan Hajnoczi pointed out in his >>> patches to port dataplane onto block layer.(Thanks, Stefan) To enable >>> this feature, I plan to enable timers to run on AioContext's thread. And >>> maybe in future, hpet can run with its dedicated thread too. >>> >>> Also, I see Alex Bligh is on the same effort by another method,(it is a >>> good idea) "[RFC] aio/async: Add timed bottom-halves". >> >> >> Stefan & Paolo did not like that method much, so I did a third method >> (posted yesterday) suggested by Stefan which adds a clock to AioContext (to >> which timers can be attached), deletes ALL the alarm_timer stuff (which was >> very cathartic), uses timeouts on the g_poll, and adds ppoll where this is >> available. Series at: >> http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg03334.html >> >> I suspect this also overlaps with your code. >> >> So now we have 3 methods to do similar things! >> >> One advantage of my approach is that it removes more code than it adds >> (by quite a margin). However, alarm timers could have been left in. >> What's the advantage in giving an AioContext its own alarm timer as >> opposed to just its own clock? >> > 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,
Timers, as used in QEMU, are not only for "unimportant" and unlikely-to-fire timeouts. They are also for potential high-rate, high resolution events. Your last series neglects this. We may need two versions of timers - or one interface that caters both use cases properly. Jan > so it can be AioContext-related. So I have patch2&5. > --2nd. You want to substitute alarm_timer with timeout of poll. > 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) > > Anything else? > > Thanks and regards, > Pingfan > >> -- >> Alex Bligh -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux
