From: Jan Kiszka <jan.kiszka@web.de>
To: "Andreas Färber" <andreas.faerber@web.de>
Cc: "qemu-trivial@nongnu.org" <qemu-trivial@nongnu.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Use SIGIO with caution
Date: Tue, 31 May 2011 23:43:13 +0200 [thread overview]
Message-ID: <4DE560F1.70407@web.de> (raw)
In-Reply-To: <DBD1BECA-1726-455B-8A11-E9E8D6C79389@web.de>
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
On 2011-05-31 23:11, Andreas Färber wrote:
> Am 31.05.2011 um 21:49 schrieb Anthony Liguori:
>
>> On 05/31/2011 11:16 AM, Alexander Graf wrote:
>>>
>>> On 31.05.2011, at 17:48, Anthony Liguori wrote:
>>>
>>>> On 05/31/2011 10:44 AM, Alexander Graf wrote:
>>>>>
>>>>> On 31.05.2011, at 16:54, Jan Kiszka wrote:
>>>>>
>>>>>> On 2011-05-31 16:26, Anthony Liguori wrote:
>>>>>>> Is there any reason we still carry multiple timer implementations
>>>>>>> these
>>>>>>> days?
>>>>>>>
>>>>>>> HPET shouldn't be any better than dynticks.
>>>>>>
>>>>>> On any recent kernel, for sure. BTW, the same applies to the RTC
>>>>>> timer.
>>>>>
>>>>> So the obvious change would be to introduce CONFIG_HPET, ifdef the
>>>>> SIGIO handling on that and also ifdef the host hpet handling code
>>>>> on it? That way it's documented well and can preferably even be
>>>>> turned off with --disable-host-hpet during configure time, which we
>>>>> can then slowly turn to the default.
>>>>
>>>> Or just remove hpet and rtc.
>>>>
>>>> Does anyone really object to that?
>
> --verbose please: We're not talking about "removal" of emulation of such
> acronyms for i386 guests, but about ceasing to use some Linux-only host
> facilities, right?
Right.
>
>>> Do RHEL5 and SLES10 support dynticks? If yes, no objections. They're
>>> the oldest really supported distros we should possibly remotely even
>>> care about.
>>
>> Yes, they do. But it's not as accurate as RTC/HPET because there is
>> no CONFIG_HRTIMERS.
>>
>> But the problem with RTC/HPET is that there is only one /dev/rtc and
>> one /dev/hpet so only one guest can use it at any given time. It's
>> really not a generally useful solution.
>>
>> At one point in time, it was the only way to get a high res clock.
>> Now, it Just Works provided you don't have an ancient kernel.
>
> I'm curious, what's ancient these days? 2.6.29 or more like 2.4.x?
IIRC, highres timers started to work around 2.6.24 on x86. Anyone on
such an old kernel is likely also not interested in updating QEMU.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2011-05-31 21:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-29 21:50 [Qemu-devel] [PATCH] Use SIGIO with caution Andreas Färber
2011-05-31 13:47 ` Anthony Liguori
2011-05-31 14:06 ` Jan Kiszka
2011-05-31 14:26 ` Anthony Liguori
2011-05-31 14:54 ` Jan Kiszka
2011-05-31 15:44 ` Alexander Graf
2011-05-31 15:48 ` Anthony Liguori
2011-05-31 16:16 ` Alexander Graf
2011-05-31 19:49 ` Anthony Liguori
2011-05-31 21:11 ` Andreas Färber
2011-05-31 21:43 ` Jan Kiszka [this message]
2011-05-31 23:19 ` Anthony Liguori
2011-05-31 14:11 ` Avi Kivity
2011-05-31 21:24 ` Andreas Färber
2011-06-01 22:30 ` [Qemu-devel] [Qemu-trivial] " Stefan Hajnoczi
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=4DE560F1.70407@web.de \
--to=jan.kiszka@web.de \
--cc=agraf@suse.de \
--cc=andreas.faerber@web.de \
--cc=avi@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.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).