1. 10 9月, 2016 2 次提交
    • L
      target-i386: present virtual L3 cache info for vcpus · 14c985cf
      Longpeng(Mike) 提交于
      Some software algorithms are based on the hardware's cache info, for example,
      for x86 linux kernel, when cpu1 want to wakeup a task on cpu2, cpu1 will trigger
      a resched IPI and told cpu2 to do the wakeup if they don't share low level
      cache. Oppositely, cpu1 will access cpu2's runqueue directly if they share llc.
      The relevant linux-kernel code as bellow:
      
      	static void ttwu_queue(struct task_struct *p, int cpu)
      	{
      		struct rq *rq = cpu_rq(cpu);
      		......
      		if (... && !cpus_share_cache(smp_processor_id(), cpu)) {
      			......
      			ttwu_queue_remote(p, cpu); /* will trigger RES IPI */
      			return;
      		}
      		......
      		ttwu_do_activate(rq, p, 0); /* access target's rq directly */
      		......
      	}
      
      In real hardware, the cpus on the same socket share L3 cache, so one won't
      trigger a resched IPIs when wakeup a task on others. But QEMU doesn't present a
      virtual L3 cache info for VM, then the linux guest will trigger lots of RES IPIs
      under some workloads even if the virtual cpus belongs to the same virtual socket.
      
      For KVM, there will be lots of vmexit due to guest send IPIs.
      The workload is a SAP HANA's testsuite, we run it one round(about 40 minuates)
      and observe the (Suse11sp3)Guest's amounts of RES IPIs which triggering during
      the period:
              No-L3           With-L3(applied this patch)
      cpu0:	363890		44582
      cpu1:	373405		43109
      cpu2:	340783		43797
      cpu3:	333854		43409
      cpu4:	327170		40038
      cpu5:	325491		39922
      cpu6:	319129		42391
      cpu7:	306480		41035
      cpu8:	161139		32188
      cpu9:	164649		31024
      cpu10:	149823		30398
      cpu11:	149823		32455
      cpu12:	164830		35143
      cpu13:	172269		35805
      cpu14:	179979		33898
      cpu15:	194505		32754
      avg:	268963.6	40129.8
      
      The VM's topology is "1*socket 8*cores 2*threads".
      After present virtual L3 cache info for VM, the amounts of RES IPIs in guest
      reduce 85%.
      
      For KVM, vcpus send IPIs will cause vmexit which is expensive, so it can cause
      severe performance degradation. We had tested the overall system performance if
      vcpus actually run on sparate physical socket. With L3 cache, the performance
      improves 7.2%~33.1%(avg:15.7%).
      Signed-off-by: NLongpeng(Mike) <longpeng2@huawei.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      14c985cf
    • L
      pc: Add 2.8 machine · a4d3c834
      Longpeng(Mike) 提交于
      This will used by the next patch.
      Signed-off-by: NLongpeng(Mike) <longpeng2@huawei.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a4d3c834
  2. 08 9月, 2016 6 次提交
  3. 07 9月, 2016 4 次提交
  4. 06 9月, 2016 16 次提交
  5. 05 9月, 2016 3 次提交
  6. 19 8月, 2016 1 次提交
  7. 18 8月, 2016 1 次提交
    • E
      block: fix deadlock in bdrv_co_flush · ce83ee57
      Evgeny Yakovlev 提交于
      The following commit
          commit 3ff2f67a
          Author: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
          Date:   Mon Jul 18 22:39:52 2016 +0300
          block: ignore flush requests when storage is clean
      has introduced a regression.
      
      There is a problem that it is still possible for 2 requests to execute
      in non sequential fashion and sometimes this results in a deadlock
      when bdrv_drain_one/all are called for BDS with such stalled requests.
      
      1. Current flushed_gen and flush_started_gen is 1.
      2. Request 1 enters bdrv_co_flush to with write_gen 1 (i.e. the same
         as flushed_gen). It gets past flushed_gen != flush_started_gen and
         sets flush_started_gen to 1 (again, the same it was before).
      3. Request 1 yields somewhere before exiting bdrv_co_flush
      4. Request 2 enters bdrv_co_flush with write_gen 2. It gets past
         flushed_gen != flush_started_gen and sets flush_started_gen to 2.
      5. Request 2 runs to completion and sets flushed_gen to 2
      6. Request 1 is resumed, runs to completion and sets flushed_gen to 1.
         However flush_started_gen is now 2.
      
      From here on out flushed_gen is always != to flush_started_gen and all
      further requests will wait on flush_queue. This change replaces
      flush_started_gen with an explicitly tracked active flush request.
      Signed-off-by: NEvgeny Yakovlev <eyakovlev@virtuozzo.com>
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Message-id: 1471457214-3994-2-git-send-email-den@openvz.org
      CC: Stefan Hajnoczi <stefanha@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: Kevin Wolf <kwolf@redhat.com>
      CC: Max Reitz <mreitz@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      ce83ee57
  8. 16 8月, 2016 1 次提交
    • D
      virtio-gpu: fix missing log.h include file · 8afc224f
      Daniel P. Berrange 提交于
      The virtio-gpu.h file defines a macro VIRTIO_GPU_FILL_CMD
      which includes a call to qemu_log_mask, but does not
      include qemu/log.h. In a default configure, it is lucky
      and gets qemu/log.h indirectly due to the 'log' trace
      backend being enabled. If that trace backend is disabled
      though, eg
      
       ./configure --enable-trace-backends=nop
      
      Then the build will fail:
      
      In file included from /home/berrange/src/virt/qemu/hw/display/virtio-gpu-3d.c:19:0:
      /home/berrange/src/virt/qemu/hw/display/virtio-gpu-3d.c: In function ‘virgl_cmd_create_resource_2d’:
      /home/berrange/src/virt/qemu/include/hw/virtio/virtio-gpu.h:138:13: error: implicit declaration of function ‘qemu_log_mask’ [-Werror=implicit-function-declaration]
                   qemu_log_mask(LOG_GUEST_ERROR,                              \
                   ^
      /home/berrange/src/virt/qemu/hw/display/virtio-gpu-3d.c:34:5: note: in expansion of macro ‘VIRTIO_GPU_FILL_CMD’
           VIRTIO_GPU_FILL_CMD(c2d);
           ^~~~~~~~~~~~~~~~~~~
      /home/berrange/src/virt/qemu/hw/display/virtio-gpu-3d.c:34:5: error: nested extern declaration of ‘qemu_log_mask’ [-Werror=nested-externs]
      In file included from /home/berrange/src/virt/qemu/hw/display/virtio-gpu-3d.c:19:0:
      /home/berrange/src/virt/qemu/include/hw/virtio/virtio-gpu.h:138:27: error: ‘LOG_GUEST_ERROR’ undeclared (first use in this function)
                   qemu_log_mask(LOG_GUEST_ERROR,                              \
      
      [snip many more errors]
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-id: 1470648700-3474-1-git-send-email-berrange@redhat.com
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      8afc224f
  9. 15 8月, 2016 1 次提交
  10. 13 8月, 2016 2 次提交
  11. 11 8月, 2016 1 次提交
  12. 10 8月, 2016 2 次提交
    • P
      clang: Fix warning reg. expansion to 'defined' · 2368635d
      Pranith Kumar 提交于
      Clang produces the following warning. The warning is detailed here:
      https://reviews.llvm.org/D15866. Fix the warning.
      
      /home/pranith/devops/code/qemu/hw/display/qxl.c:507:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
          ^
      /home/pranith/devops/code/qemu/include/ui/qemu-spice.h:46:5: note: expanded from macro 'SPICE_NEEDS_SET_MM_TIME'
        (!defined(SPICE_SERVER_VERSION) || (SPICE_SERVER_VERSION < 0xc06))
          ^
      /home/pranith/devops/code/qemu/hw/display/qxl.c:1074:5: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined]
          ^
      /home/pranith/devops/code/qemu/include/ui/qemu-spice.h:46:5: note: expanded from macro 'SPICE_NEEDS_SET_MM_TIME'
        (!defined(SPICE_SERVER_VERSION) || (SPICE_SERVER_VERSION < 0xc06))
      Suggested-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      2368635d
    • P
      atomic: strip "const" from variables declared with typeof · 5927ed84
      Paolo Bonzini 提交于
      With the latest clang, we have the following warning:
      
          /home/pranith/devops/code/qemu/include/qemu/seqlock.h:62:21: warning: passing 'typeof (*&sl->sequence) *' (aka 'const unsigned int *') to parameter of type 'unsigned int *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
              return unlikely(atomic_read(&sl->sequence) != start);
                              ^~~~~~~~~~~~~~~~~~~~~~~~~~
          /home/pranith/devops/code/qemu/include/qemu/atomic.h:58:25: note: expanded from macro 'atomic_read'
              __atomic_load(ptr, &_val, __ATOMIC_RELAXED);     \
                                 ^~~~~
      
      Stripping const is a bit tricky due to promotions, but it is doable
      with either C11 _Generic or GCC extensions.  Use the latter.
      Reported-by: NPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      [pranith: Add conversion for bool type]
      Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5927ed84