On 02/13/2015 09:02 PM, Oleg Nesterov wrote:
On 02/13, Raghavendra K T wrote:
@@ -164,7 +161,7 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
{
struct __raw_tickets tmp = READ_ONCE(lock-tickets);
- return tmp.tail != tmp.head;
+ return tmp.tail !=
On Sun, Feb 15, 2015 at 3:30 PM, Ding Xiao ssdxiaod...@gmail.com
wrote:
I am test virtio-vhost in 10G environment
host info
cpu E2680@2.7GHz
memory 16G
network intel 82599BE
os centos 7
VM info
cpu 4
memory 4G
network using virtio vhost
os centos 7
I using pktgen to send udp package, the
On 02/15/2015 11:25 AM, Raghavendra K T wrote:
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
I am test virtio-vhost in 10G environment
host info
cpu E2680@2.7GHz
memory 16G
network intel 82599BE
os centos 7
VM info
cpu 4
memory 4G
network using virtio vhost
os centos 7
I using pktgen to send udp package, the result like follow
64b 230Mb/s
1400b 5.9Gb/s
I test the speed in VMware too,
Paravirt spinlock clears slowpath flag after doing unlock.
As explained by Linus currently it does:
prev = *lock;
add_smp(lock-tickets.head, TICKET_LOCK_INC);
/* add_smp() is a full mb() */
if (unlikely(lock-tickets.tail
https://bugzilla.kernel.org/show_bug.cgi?id=93251
Bug ID: 93251
Summary: qemu-kvm guests randomly hangs after reboot command in
guest
Product: Virtualization
Version: unspecified
Kernel Version: 3.19.0
Hardware: Intel
https://bugzilla.kernel.org/show_bug.cgi?id=93251
--- Comment #1 from Ondřej Súkup mimi...@gmail.com ---
I run about 7 nodes, an simulate build of openstack cloud in qemu-kvm env ..
nodes randomly after reboot stop working, or hangs in few sec after reboot
from journalctl:
úno 13 18:10:22
On Tue, Feb 03, 2015 at 11:58:17PM +0800, Wincy Van wrote:
If vcpu has a interrupt in vmx non-root mode, we will
kick that vcpu to inject interrupt timely. With posted
interrupt processing, the kick intr is not needed, and
interrupts are fully taken care of by hardware.
In nested vmx, this
