On 04/05/2010 12:53 AM, Paul Brook wrote:
Surprising as there are ~10 descriptors being
polled, so ~1200 polls per second. Maybe epoll will help here.
I'm not sure where you get 1200 from. select will be called once per host
wakeup. i.e. if the USB controller is enabled then 1k times p
> > My guess is that the overhead you're seeing is entirely from the USB host
> > adapter having to wake up and check the transport descriptor lists. This
> > will only result in the guest being woken if a device actually responds
> > (as mentioned above it should not).
>
> A quick profile on the
> > The USB HID devices implement the SET_IDLE command, so the polling
> > interval will have no real effect on performance.
>
> On a Linux guest (F12), I see 125 USB interrupts per second with no
> mouse movement, so something is broken (on the guest or host).
Turns out to be a a bug in the UHCI
On 04/04/2010 05:25 PM, Paul Brook wrote:
Looks like the tablet is set to 100 Hz polling rate. We may be able
to get away with 30 Hz or even less (ep_bInterval, in ms, in
hw/usb-wacom.c).
Changing the USB tablet polling interval from 10ms to 100ms in both
hw/usb-wacom.c and hw/usb-hid.c
> > Looks like the tablet is set to 100 Hz polling rate. We may be able
> > to get away with 30 Hz or even less (ep_bInterval, in ms, in
> > hw/usb-wacom.c).
>
> Changing the USB tablet polling interval from 10ms to 100ms in both
> hw/usb-wacom.c and hw/usb-hid.c made no difference except the an i
Avi Kivity writes:
> On 03/02/2010 11:34 AM, Jernej Simončič wrote:
> >On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote:
> >
> >>I remember about a year ago, someone asserting on the list that -usbdevice
> >>tablet was very CPU intensive even when not in use, and should be avoided if
> >>mous
On 03/09/2010 07:27 PM, Anthony Liguori wrote:
Perhaps a json representation of things. We already have the parser.
Please no :-)
We have a config format, QemuOpts ties nicely into it as does qdev.
We just need to represent machine information via QemuOpts and tie -m
to manipulating the m
On 03/09/2010 11:11 AM, Avi Kivity wrote:
On 03/09/2010 04:57 PM, Anthony Liguori wrote:
On 03/09/2010 08:52 AM, Avi Kivity wrote:
On 03/09/2010 04:50 PM, Anthony Liguori wrote:
It's all in the openSUSE build service. The direct access URL
(login required FWIW) is here:
https://build.opensus
On 03/09/2010 04:57 PM, Anthony Liguori wrote:
On 03/09/2010 08:52 AM, Avi Kivity wrote:
On 03/09/2010 04:50 PM, Anthony Liguori wrote:
It's all in the openSUSE build service. The direct access URL
(login required FWIW) is here:
https://build.opensuse.org/package/view_file?file=kvm-qemu-defau
On 03/09/2010 08:52 AM, Avi Kivity wrote:
On 03/09/2010 04:50 PM, Anthony Liguori wrote:
It's all in the openSUSE build service. The direct access URL (login
required FWIW) is here:
https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualizat
On 03/09/2010 04:49 PM, Anthony Liguori wrote:
On 03/09/2010 07:32 AM, Avi Kivity wrote:
On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that
bumps the default to 384 for qemu-kvm. That was the first "round"
number where an openSUSE ins
On 03/09/2010 04:50 PM, Anthony Liguori wrote:
It's all in the openSUSE build service. The direct access URL (login
required FWIW) is here:
https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization
It merely changes DEFAULT_RAM_SIZE
On 03/09/2010 08:38 AM, Alexander Graf wrote:
On 09.03.2010, at 15:32, Dustin Kirkland wrote:
On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote:
On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that bumps
the default
On 03/09/2010 07:32 AM, Avi Kivity wrote:
On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that
bumps the default to 384 for qemu-kvm. That was the first "round"
number where an openSUSE installation worked.
If someone works up a patch
On 09.03.2010, at 15:32, Dustin Kirkland wrote:
> On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote:
>> On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that bumps
the default to 384 for qemu-kvm. That was the first "round" num
On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote:
> On 03/02/2010 04:36 AM, Anthony Liguori wrote:
> >> I keep a patch in the SUSE version for quite some time now that bumps
> >> the default to 384 for qemu-kvm. That was the first "round" number
> >> where an openSUSE installation worked.
> >
On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that bumps
the default to 384 for qemu-kvm. That was the first "round" number
where an openSUSE installation worked.
If someone works up a patch and tests at least a couple types of
guest
On 03/07/2010 08:53 PM, Arnaldo Carvalho de Melo wrote:
Do you really think that more kernel developers would use perf more
frequently if it had some GUI?
Not much. Is perf's target kernel developers exclusively? Who are
we writing this kernel for?
No, we aren't writing this too
Em Sun, Mar 07, 2010 at 08:15:40PM +0200, Avi Kivity escreveu:
> On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote:
> >Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
> >>perf really is wonderful, but to be really competitive, and usable to
> >>more developers, it needs to be in
* Pekka Enberg wrote:
> That said, AFAICT, it should be pretty simple to implement a shark-like UI
> with GTK as current perf code is pretty good fit for that. I've pondered
> about doing that myself but quite frankly, I don't see any big gains in
> that.
There's a perf events based GUI: sys
On 03/02/2010 02:30 AM, Ingo Molnar wrote:
* Anthony Liguori wrote:
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:
- It's much easier to synchronize new features on the kern
On 02/27/2010 07:25 PM, Ingo Molnar wrote:
* Zachary Amsden wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code quality of qemu
On 03/07/2010 05:14 PM, Luca Barbieri wrote:
perf really is wonderful, but to be really competitive, and usable to more
developers, it needs to be in a graphical environment. I want 'perf report'
output to start out collapsed and drill down by clicking on a tree widget.
Clicking on a function
On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote:
Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
perf really is wonderful, but to be really competitive, and usable to
more developers, it needs to be in a graphical environment. I want
'perf report' output to start out c
Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
> perf really is wonderful, but to be really competitive, and usable to
> more developers, it needs to be in a graphical environment. I want
> 'perf report' output to start out collapsed and drill down by clicking
> on a tree wid
> perf really is wonderful, but to be really competitive, and usable to more
> developers, it needs to be in a graphical environment. I want 'perf report'
> output to start out collapsed and drill down by clicking on a tree widget.
> Clicking on a function name opens its definition. 'perf annota
On 03/03/2010 05:42 PM, Ross Boylan wrote:
Of course this is itself still far from optimal
as a user experiance. We really want it to be fully configured to any
resolution as easily as the user would do with a real graphics card&
monitor.
Is there some obstacle to getting the virtual monit
On 03/02/2010 11:34 AM, Jernej Simončič wrote:
On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote:
I remember about a year ago, someone asserting on the list that -usbdevice
tablet was very CPU intensive even when not in use, and should be avoided if
mouse support wasn't needed, e.g. on n
On 03/01/2010 05:14 PM, Anthony Liguori wrote:
- Graphics performance is awful even with the 640x480 miniature
version.
During bootup I can see it drawing single characters. This is a
Core2
2.8GHz.
That's a bug. Please report it. Graphics performance isn't great,
but it should n
On 03/07/2010 11:56 AM, Pekka Enberg wrote:
Hi Avi,
(slightly off-topic)
On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity wrote:
perf really is wonderful, but to be really competitive, and usable to more
developers, it needs to be in a graphical environment. I want 'perf report'
output to sta
Hi Avi,
(slightly off-topic)
On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity wrote:
> perf really is wonderful, but to be really competitive, and usable to more
> developers, it needs to be in a graphical environment. I want 'perf report'
> output to start out collapsed and drill down by clicking o
On 03/02/2010 12:30 PM, Ingo Molnar wrote:
* Ingo Molnar wrote:
Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:
- It's much easier to synchronize new features on the kernel side and on the
user-space side. The two go han
On 03/02/2010 04:29 PM, Ingo Molnar wrote:
I guess the first step would be to move away from the 'lets support lots of
crappy virtualization solutions at once, poorly' model, and pick one good
combo (i'd go for Qemu+KVM) and turn it into a heck of an all-around solution.
Then all the other combo
"H. Peter Anvin" writes:
> On 03/04/2010 12:13 PM, Zachary Amsden wrote:
>>
>> These are all basic things that are left completely undefined by qemu's
>> lack of a top-level configuration file, and it's an inexcusable disgrace.
>>
>
> There is a top-level configuration file for Qemu, at least
On 03/04/2010 12:13 PM, Zachary Amsden wrote:
>
> These are all basic things that are left completely undefined by qemu's
> lack of a top-level configuration file, and it's an inexcusable disgrace.
>
There is a top-level configuration file for Qemu, at least in the
development tree. It's optio
On 03/04/2010 02:13 PM, Zachary Amsden wrote:
The biggest problem with virt-manager isn't virt-manager, it's that it
is trying to do a nearly intractable task. Because a qemu virtual
machine is not a machine at all, just a disk image without the proper
metadata to track the important propert
On 03/04/2010 10:00 AM, Lucas Meneghel Rodrigues wrote:
On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote:
On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
The real
question to ask is, why are you using qemu directly instead of using
virt-manager?
Because I sus
On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote:
> On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
> > The real
> > question to ask is, why are you using qemu directly instead of using
> > virt-manager?
>
> Because I suspect Ingo, like me, is a command line user, launching a g
On Wed, 2010-03-03 at 08:55 +, Daniel P. Berrange wrote:
> On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote:
> > On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
> > >
> > > > * desktop is 1024 x 720
> > > >
> > >
> > > 1024x768 and this is what the default is today
On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote:
> On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
> >
> > > * desktop is 1024 x 720
> > >
> >
> > 1024x768 and this is what the default is today anyway.
> That was not my experience, as reported in my post a few days ago
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
>
> > * desktop is 1024 x 720
> >
>
> 1024x768 and this is what the default is today anyway.
That was not my experience, as reported in my post a few days ago
("800x600 max resolution"), nor is it the experience reported in the
messa
On 03/02/10 15:56, Daniel P. Berrange wrote:
Glad to hear that. Are these bits in F12 virt-preview already?
I believe so.
/me goes fetch updates to check it out.
Migrating
>from another tool like VMWare is a much harder than just importing
the disk image, since you have to update the dr
On Tue, Mar 02, 2010 at 03:52:52PM +0100, Gerd Hoffmann wrote:
> On 03/02/10 15:37, Daniel P. Berrange wrote:
> >On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:
> >>On 03/02/10 14:37, Nikolai K. Bochev wrote:
> >>>I don't see where this argument is leading to. So far there are
> >>>a
On Tue, Mar 2, 2010 at 2:21 AM, Chris Webb wrote:
> I remember about a year ago, someone asserting on the list that -usbdevice
> tablet was very CPU intensive even when not in use, and should be avoided if
> mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a
> significant
On 03/02/10 15:37, Daniel P. Berrange wrote:
On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:
On 03/02/10 14:37, Nikolai K. Bochev wrote:
I don't see where this argument is leading to. So far there are
arguments that qemu/kvm sucks as a desktop virtualization, now
suddenly the gui
On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:
> On 03/02/10 14:37, Nikolai K. Bochev wrote:
> >I don't see where this argument is leading to. So far there are
> >arguments that qemu/kvm sucks as a desktop virtualization, now
> >suddenly the gui tools are shitty and everything shoul
* Gerd Hoffmann wrote:
> On 03/02/10 14:37, Nikolai K. Bochev wrote:
> >I don't see where this argument is leading to. So far there are
> >arguments that qemu/kvm sucks as a desktop virtualization, now
> >suddenly the gui tools are shitty and everything should be done cli ,
> >because there's no
On 03/02/10 14:37, Nikolai K. Bochev wrote:
I don't see where this argument is leading to. So far there are
arguments that qemu/kvm sucks as a desktop virtualization, now
suddenly the gui tools are shitty and everything should be done cli ,
because there's no man pages for virt-manager. Explain.
Sent: Tue, 02 Mar 2010 12:11:06 +0200 (EET)
Subject: Re: KVM usability
On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
> The real
> question to ask is, why are you using qemu directly instead of using
> virt-manager?
Because I suspect Ingo, like me, is a command line user,
* Ingo Molnar wrote:
> Here's our experience with tools/perf/. Hosting the project in the kernel
> proper helped its quality immensely:
>
> - It's much easier to synchronize new features on the kernel side and on the
>user-space side. The two go hand in hand - they are often implemented i
On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
> The real
> question to ask is, why are you using qemu directly instead of using
> virt-manager?
Because I suspect Ingo, like me, is a command line user, launching a gui
to start kvm when there is a kvm command around just sounds daft.
Ingo Molnar writes:
> Yes, you are quite correct: udev has been argued to be a prime candidate for
> tools/. (and some other kernel utilities as well)
A small, static set of userspace like klibc (only 5M unpacked!) with enough
tools for rolling up in a standard initramfs would be especially nic
Dustin Kirkland writes:
> On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
> >
> > Defaulting usb to on and defaulting to a usb tablet is a reasonable
> > thing to do IMHO.
>
> \o/ Definitely a better user experience.
I remember about a year ago, someone asserting on the list that -
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
> On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
> > kvm -m 512 -cdrom
> > /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
> > file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on
>
On 03/01/2010 08:34 PM, Alexander Graf wrote:
On 01.03.2010, at 22:59, Anthony Liguori wrote:
On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
kvm -m 512 -cdrom
/home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
file=/home/kirkland/.cache/testdrive/img/testdrive-disk-00
On 01.03.2010, at 22:59, Anthony Liguori wrote:
> On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
>> kvm -m 512 -cdrom
>> /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
>> file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on
>> -usb -usbd
On 03/01/2010 06:30 PM, Ingo Molnar wrote:
IMO that's a bug, not a feature. There should be a lot more interaction
between kvm-qemu and KVM: for example Qemu should have a feature to install
paravirt drivers in the guest, this would be helped by living in the kernel
repo.
Not in the slighte
On Mon, Mar 1, 2010 at 9:14 AM, Anthony Liguori wrote:
> On 02/27/2010 04:56 AM, Ingo Molnar wrote:
>> - But i'm a more advanced user so i dont need help screens, i knew that
>> the
>> "go full screen" hotkey is:
>>
>> LeftCtrl-LeftALT-F
>>
>> ... except that it is a one-way road
* Zachary Amsden wrote:
> On 03/01/2010 11:45 AM, Anthony Liguori wrote:
> >On 03/01/2010 02:56 PM, Ingo Molnar wrote:
> >
> >> - Code distribution is easy: it comes with the kernel. This
> >>spreads the code
> >>far and wide. It's easy for kernel developers to jump in and
> >>help out, the
* Anthony Liguori wrote:
> On 03/01/2010 02:56 PM, Ingo Molnar wrote:
> >Here's our experience with tools/perf/. Hosting the project in the kernel
> >proper helped its quality immensely:
> >
> > - It's much easier to synchronize new features on the kernel side and on
> > the
> >user-space
On 03/01/2010 11:45 AM, Anthony Liguori wrote:
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
- Code distribution is easy: it comes with the kernel. This spreads
the code
far and wide. It's easy for kernel developers to jump in and help
out, the
latest devel code is always there, a singl
On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
kvm -m 512 -cdrom
/home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on
-usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370
On 03/01/2010 02:56 PM, Ingo Molnar wrote:
Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:
- It's much easier to synchronize new features on the kernel side and on the
user-space side. The two go hand in hand - they are often i
On Sat, Feb 27, 2010 at 4:56 AM, Ingo Molnar wrote:
> Here's my experience with it:
>
> - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my
> 1680x1050 laptop screen. It's so small that initially i even overlooked
> that i started it. It should multiplex pixels up to
* Zachary Amsden wrote:
> > I guess there is some misunderstanding here, the tools/ directory that
> > lives in the kernel _sources_, has no kernel source, its all userspace
> > stuff.
>
> Yeah, no morning coffee :=)
>
> So instead we are advocating forking qemu into the kernel. That makes
On 03/01/2010 07:41 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu:
On 02/27/2010 07:25 AM, Ingo Molnar wrote:
I'm not talking about moving it into a kernel _module_ - albeit that
alone is a worthwile thing to do for any performan
Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu:
> On 02/27/2010 07:25 AM, Ingo Molnar wrote:
>> I'm not talking about moving it into a kernel _module_ - albeit that
>> alone is a worthwile thing to do for any performance sensitive hw
>> component.
>>
>> I was talking about the op
On 02/27/2010 07:25 AM, Ingo Molnar wrote:
* Zachary Amsden wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code quality of qemu
On Mon, Mar 01, 2010 at 09:14:02AM -0600, Anthony Liguori wrote:
> On 02/27/2010 04:56 AM, Ingo Molnar wrote:
>
> The other type of user we target is power virtualization/emulation
> users. We certainly could do better for this type of user but it's
> never going to fit what your expectation of
On 03/01/2010 03:25 AM, Ingo Molnar wrote:
* Zachary Amsden wrote:
Here's my experience with it:
- qemu-kvm starts up with a miniature resolution by default. 640x480 - on my
1680x1050 laptop screen. It's so small that initially i even overlooked
that i started it. It should mult
On 02/27/2010 11:25 AM, Ingo Molnar wrote:
* Zachary Amsden wrote:
[...]
Second, it's not over-modularized. The modules are the individual
components of the architecture. How would you propose to put it
differently. They really can't naturally combine. And with the
code quality of qemu
On 02/27/2010 04:56 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
Nobody is really 'in charge' of how KVM gets delivered to the user. You
isolated the fun kernel part for you and pushed out the boring bits to
user-space. So if mundane things l
* Zachary Amsden wrote:
> > Here's my experience with it:
> >
> > - qemu-kvm starts up with a miniature resolution by default. 640x480 - on
> > my
> >1680x1050 laptop screen. It's so small that initially i even overlooked
> >that i started it. It should multiplex pixels up to a reasona
* Zachary Amsden wrote:
[...]
>
> Second, it's not over-modularized. The modules are the individual
> components of the architecture. How would you propose to put it
> differently. They really can't naturally combine. And with the
> code quality of qemu in general being problematic by Linux
Ingo Molnar wrote:
> I'm not trolling you at all: is it _really_ not obvious to you that the
> KVM/qemu usability status quo honestly sucks, to an unbiased observer?
I agree that for desktop-style (e.g. vmware workstation) style
virtualisation, the plain QEMU+KVM package is terrible.
However, in
On 02/27/2010 12:56 AM, Ingo Molnar wrote:
* Avi Kivity wrote:
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
Nobody is really 'in charge' of how KVM gets delivered to the user. You
isolated the fun kernel part for you and pushed out the boring bits to
user-space. So if mundane things l
[ adding qemu-devel to CC as most issues concern that project as well ]
Ingo Molnar wrote:
> * Avi Kivity wrote:
>
>> On 02/26/2010 01:17 PM, Ingo Molnar wrote:
>>> Nobody is really 'in charge' of how KVM gets delivered to the user. You
>>> isolated the fun kernel part for you and pushed out the
77 matches
Mail list logo
