search for: 3us

...From VM side, it might be better to use one hardware queue per vCPU, since in theory it can remove vq lock contention. But from host side, there is still disadvantage with more queues, since more queues means more notify times, in my virtio-blk test, even with ioeventfd, one notification may take ~3us averagely on qemu-system-x86_64. For virtio-blk, I don't think it is always better to take more queues, and we need to leverage below things in host side: - host storage top performance, generally it reaches that with more than 1 jobs with libaio(suppose it is N, so basically we can use N iot...

Il 17/06/2014 18:00, Ming Lei ha scritto: >> > If you want to do queue steering based on the guest VCPU number, the number >> > of queues must be = to the number of VCPUs shouldn't it? >> > >> > I tried using a divisor of the number of VCPUs, but couldn't get the block >> > layer to deliver interrupts to the right VCPU. > For blk-mq's

Il 17/06/2014 18:00, Ming Lei ha scritto: >> > If you want to do queue steering based on the guest VCPU number, the number >> > of queues must be = to the number of VCPUs shouldn't it? >> > >> > I tried using a divisor of the number of VCPUs, but couldn't get the block >> > layer to deliver interrupts to the right VCPU. > For blk-mq's

Hi all, I need a periodic timer running at ideally at 125 microseconds and at least 500 microseconds. I''ve just found the VCPUOP_set_periodic_timer, however there is a comment saying "periods less than one millisecond may not be supported". I will be running on an x64 machine. Is this supported? If not, is there any alternate means of generating a fast interrupt? Regards.

Hi, I have done some debugging to find out the root cause of bug 1282, which has the following symptoms with paravirtualized guests: - after a live migrate, the time on the guest can jump - after a live migrate, the guest "forgets" to wake up processes - after a domU save, dom0 reboot and domU restore, the time is correct but processes are not woken up from sys_nanosleep The problem

https://bugs.freedesktop.org/show_bug.cgi?id=89558 Bug ID: 89558 Summary: Unknown chipset error for GeForce 840M Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking