[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [RFC PATCH v2 0/2] Add a new acquire resource to query vcpu statistics
Hello all, The purpose of this RFC is to get feedback about a new acquire resource that exposes vcpu statistics for a given domain. The current mechanism to get those statistics is by querying the hypervisor. This mechanism relies on a hypercall and holds the domctl spinlock during its execution. When a pv tool like xcp-rrdd periodically samples these counters, it ends up affecting other paths that share that spinlock. By using acquire resources, the pv tool only requires a few hypercalls to set the shared memory region and samples are got without issuing any other hypercall. The original idea has been suggested by Andrew Cooper to which I have been discussing about how to implement the current PoC. You can find the RFC patch series at [1]. The series is rebased on top of stable-4.15. I am currently a bit blocked on 1) what to expose and 2) how to expose it. For 1), I decided to expose what xcp-rrdd is querying, e.g., XEN_DOMCTL_getvcpuinfo. More precisely, xcp-rrd gets runstate.time[RUNSTATE_running]. This is a uint64_t counter. However, the time spent in other states may be interesting too. Regarding 2), I am not sure if simply using an array of uint64_t is enough or if a different interface should be exposed. The remaining question is when to get new values. For the moment, I am updating this counter during vcpu_runstate_change(). The current series includes a simple pv tool that shows how this new interface is used. This tool maps the counter and periodically samples it. Any feedback/help would be appreciated. Thanks, Matias. [1] https://github.com/MatiasVara/xen/tree/feature_stats Changes in v2: - rework to ensure that consumer fetches consistent data Changes in v1: - rework how the resource is allocated and released - rework when the resource is allocated that happens only when the resource is requested - rework the structure shared between the tool and Xen to make it extensible to new counters and declare it in a public header There are still the following questions: - resource shall be released when there are no more readers otherwise we keep updating it during a hot path - one frame can host up to 512 vcpus. Should I check to this limit when updating? Should it be possible to allocate more than one frame for vcpu counters? Matias Ezequiel Vara Larsen (2): xen/memory : Add a stats_table resource type tools/misc: Add xen-vcpus-stats tool tools/misc/Makefile | 6 +++ tools/misc/xen-vcpus-stats.c | 87 +++++++++++++++++++++++++++++++++ xen/arch/x86/hvm/hvm.c | 2 + xen/common/memory.c | 94 ++++++++++++++++++++++++++++++++++++ xen/common/sched/core.c | 16 ++++++ xen/include/public/memory.h | 3 ++ xen/include/public/vcpu.h | 16 ++++++ xen/include/xen/mm.h | 2 + xen/include/xen/sched.h | 5 ++ 9 files changed, 231 insertions(+) create mode 100644 tools/misc/xen-vcpus-stats.c -- 2.25.1
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |