On Tue, 2007-08-21 at 00:33 -0700, Dor Laor wrote:
Well, for cache reasons you should really try to avoid having both
sides
write to the same data. Hence two separate cache-aligned regions
is
better than one region and a flip bit.
While I certainly can see what you mean about the
Am Montag, 20. August 2007 schrieb Glauber de Oliveira Costa:
Although I don't know KVM to a that deep level, I think it should be
possible to keep the virtual cpus in different process (or threads),
and take the accounting time from there. Perfectly possible to know
the time we spent running
Hello Rusty,
I think I have found a problem in the virtio network driver. virtio_net
reclaims sent skbs on xmit. That means that there is always one skb
outstanding and the netdev packet statistic is always one packet to low.
Documentation/networking/drivers.txt says
3) Do not forget that
On Tue, 2007-08-21 at 17:58 +1000, Rusty Russell wrote:
Partly the horror of the code, but mainly because it is an in-order
ring. You'll note that we use a reply ring, so we don't need to know
how much the other side has consumed (and it needn't do so in order).
I have certainly been known
Rusty Russell wrote:
Partly the horror of the code, but mainly because it is an in-order
ring. You'll note that we use a reply ring, so we don't need to know
how much the other side has consumed (and it needn't do so in order).
Yes, it's quite nice: by using two in-order rings, you get
Jeremy Fitzhardinge wrote:
Laurent Vivier wrote:
functionnalities:
- allow to measure time spent by a CPU in a virtual CPU.
- allow to display in /proc/state this value by CPU
- allow to display in /proc/pid/state this value by process
- allow KVM to use these 3 previous functionnalities
On Tue, 2007-08-21 at 08:00 -0400, Gregory Haskins wrote:
On Tue, 2007-08-21 at 17:58 +1000, Rusty Russell wrote:
Partly the horror of the code, but mainly because it is an in-order
ring. You'll note that we use a reply ring, so we don't need to know
how much the other side has consumed
On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:
Hi Gregory,
The main current use is disk drivers: they process out-of-order.
Maybe for you ;) I am working on the networking/IVMC side.
I think the use of rings for the tx-path in of
itself is questionable unless you can
On Tuesday 21 August 2007, Rusty Russell wrote:
One solution would be to use the xmit_done interrupt. Unfortunately this
would
require additional locking as multiple interrupts can happen at two or more
cpus. Do you have any better ideas?
The only reason that we don't do it in
Am Dienstag, 21. August 2007 schrieb Rusty Russell:
The only reason that we don't do it in skb_xmit_done() is because
kfree_skb() isn't supposed to be called from an interrupt. But there's
dev_kfree_skb_any() which can be used.
Ok, I now hacked something that works but I really dont like the
On Tue, 2007-08-21 at 10:06 -0400, Gregory Haskins wrote:
On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:
In the guest - host direction, an interface like virtio is designed
for batching, with the explicit distinction between add_buf sync.
Right. IOQ has iter_push() and
Gregory Haskins wrote:
On Tue, 2007-08-21 at 10:06 -0400, Gregory Haskins wrote:
On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:
In the guest - host direction, an interface like virtio is designed
for batching, with the explicit distinction between add_buf sync.
On Tue, 2007-08-21 at 20:12 +0300, Avi Kivity wrote:
No, sync() means make the other side aware that there's work to be done.
Ok, but still the important thing isn't the kick per se, but the
resulting completetion. Can we do interrupt driven reclamation? Some
of those virtio_net emails I
On lunedì 20 agosto 2007, Joe Perches wrote:
(untested)
There are several files that
#include linux/file not #include linux/file
#include asm/file not #include asm/file
Here's a little script that converts them:
egrep -i -r -l --include=*.[ch] \
On 8/21/07, Laurent Vivier [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
by doing this at kernel level, we can:
- measure exactly the guest time,
- move this part of system time to user time (as you think it should be
user time),
- have consistency between system, user and
On 8/21/07, Christian Borntraeger [EMAIL PROTECTED] wrote:
Am Montag, 20. August 2007 schrieb Glauber de Oliveira Costa:
Although I don't know KVM to a that deep level, I think it should be
possible to keep the virtual cpus in different process (or threads),
and take the accounting time
Found this looping Ubuntu installs with VMI.
If unlucky enough to hit a vmalloc sync fault during a lazy mode
operation (from an IRQ handler for a module which was not yet populated
in current page directory, or from inside copy_one_pte, which touches
swap_map, and hit in an unused 4M
On Tue, 2007-08-21 at 17:06 +0200, Arnd Bergmann wrote:
On Tuesday 21 August 2007, Rusty Russell wrote:
One solution would be to use the xmit_done interrupt. Unfortunately this
would
require additional locking as multiple interrupts can happen at two or
more
cpus. Do you have
On Tue, 2007-08-21 at 12:47 -0400, Gregory Haskins wrote:
On Tue, 2007-08-21 at 10:06 -0400, Gregory Haskins wrote:
On Tue, 2007-08-21 at 23:47 +1000, Rusty Russell wrote:
In the guest - host direction, an interface like virtio is designed
for batching, with the explicit distinction
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest OS.
Not only is the trap for a #GP heavyweight, both in the processor and
the
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance
problems. The I/O can not be completed physically, but must be
virtualized. This means trapping and decoding port I/O instructions
from the guest OS. Not only is the trap for a #GP heavyweight, both
in the
Avi Kivity wrote:
Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance
problems. The I/O can not be completed physically, but must be
virtualized. This means trapping and decoding port I/O instructions
from the guest OS. Not only is the trap for a #GP
22 matches
Mail list logo
