Hi, It seems that this series has been stale for more than a month with no comment from maintainer for patch#1 [1] and actions needed from author for patch#2 [2]. So sending this email as a gentle reminder. Thanks! [1] https://patchwork.kernel.org/project/xen-devel/patch/d0afb6657b1e78df4857ad7bcc875982e9c022b4.1652797713.git.matias.vara@vates.fr/ [2] https://patchwork.kernel.org/project/xen-devel/patch/e233c4f60c6fe97b93b3adf9affeb0404c554130.1652797713.git.matias.vara@vates.fr/ Kind regards, Henry > -----Original Message----- > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of > Matias Ezequiel Vara Larsen > Subject: [RFC PATCH 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 > > Matias Ezequiel Vara Larsen (2): > xen/memory : Add stats_table resource type > tools/misc: Add xen-stats tool > > tools/misc/Makefile | 5 +++ > tools/misc/xen-stats.c | 83 +++++++++++++++++++++++++++++++++++++ > xen/common/domain.c | 42 +++++++++++++++++++ > xen/common/memory.c | 29 +++++++++++++ > xen/common/sched/core.c | 5 +++ > xen/include/public/memory.h | 1 + > xen/include/xen/sched.h | 5 +++ > 7 files changed, 170 insertions(+) > create mode 100644 tools/misc/xen-stats.c > > -- > 2.25.1 >
© 2016 - 2024 Red Hat, Inc.