similar to: Re: [PATCH] remove blocked time accounting from xen "clockchip"

Hi, I am not sure, but I think this may be a process accounting bug. If interrupts are disabled for a considerable amount of time ( say multiple ticks), the process accounting code will still account a single tick for such cases, on the next interrupt tick. Shouldn't we have some way to fix that case like we do for NO_HZ restart_sched_tick case, where we account for multiple idle ticks.

Hi, I am not sure, but I think this may be a process accounting bug. If interrupts are disabled for a considerable amount of time ( say multiple ticks), the process accounting code will still account a single tick for such cases, on the next interrupt tick. Shouldn't we have some way to fix that case like we do for NO_HZ restart_sched_tick case, where we account for multiple idle ticks.

This patch fixes the following errors caused by 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d which changed the prototypes of account_steal_time() and account_idle_time(). > CC arch/ia64/xen/time.o > arch/ia64/xen/time.c: In function 'consider_steal_time': > arch/ia64/xen/time.c:132: warning: passing argument 1 of 'account_steal_time' makes integer from pointer without

This patch fixes the following errors caused by 79741dd35713ff4f6fd0eafd59fa94e8a4ba922d which changed the prototypes of account_steal_time() and account_idle_time(). > CC arch/ia64/xen/time.o > arch/ia64/xen/time.c: In function 'consider_steal_time': > arch/ia64/xen/time.c:132: warning: passing argument 1 of 'account_steal_time' makes integer from pointer without

Hi all, this patch series introduces stolen ticks accounting for Xen on ARM. Stolen ticks are clocksource ticks that have been "stolen" from the cpu, typically because Linux is running in a virtual machine and the vcpu has been descheduled. To account for these ticks we introduce CONFIG_PARAVIRT and pv_time_ops so that we can make use of:

Pipeline #819889104 has failed! Project: libnbd ( https://gitlab.com/nbdkit/libnbd ) Branch: master ( https://gitlab.com/nbdkit/libnbd/-/commits/master ) Commit: 2db30279 ( https://gitlab.com/nbdkit/libnbd/-/commit/2db30279bad4f9923baa541008f5da11624d2d1f ) Commit Message: socket activation: set LISTEN_FDNAMES Add LIST... Commit Author: Laszlo Ersek ( https://gitlab.com/lersek ) Pipeline

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 20079 qemu-upstream-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/20079/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking:

"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 20078 qemu-upstream-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/20078/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking:

On 3/28/23 08:59, GitLab wrote: > GitLab > ? Pipeline #819889104 has failed! > > ? > Project nbdkit <https://gitlab.com/nbdkit> / libnbd > <https://gitlab.com/nbdkit/libnbd> > Branch > master <https://gitlab.com/nbdkit/libnbd/-/commits/master> > > Commit > 2db30279 >

From: Gerd Hoffmann <kraxel at redhat.com> [ Upstream commit 9b2a0a1ef66f96bf34921a3865581eca32ff05ec ] We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Suggested-by: Laszlo Ersek <lersek at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by:

Pipeline #785487102 has failed! Project: libnbd ( https://gitlab.com/nbdkit/libnbd ) Branch: master ( https://gitlab.com/nbdkit/libnbd/-/commits/master ) Commit: b5101fbc ( https://gitlab.com/nbdkit/libnbd/-/commit/b5101fbc59cbdaef47e7843c735e8cc9f63fce10 ) Commit Message: use space consistently in function and function... Commit Author: Laszlo Ersek ( https://gitlab.com/lersek ) Pipeline

Pipeline #813094663 has failed! Project: libnbd ( https://gitlab.com/nbdkit/libnbd ) Branch: master ( https://gitlab.com/nbdkit/libnbd/-/commits/master ) Commit: 65631e5d ( https://gitlab.com/nbdkit/libnbd/-/commit/65631e5dfff5d0b8f691aba1e838c83dceb621d0 ) Commit Message: lib/utils: try to placate attribute placement r... Commit Author: Laszlo Ersek ( https://gitlab.com/lersek ) Pipeline

The aim of these four patches is to introduce Virtual Machine time accounting. _Ingo_, as these patches modify files of the scheduler, could you have a look to them, please ? [PATCH 1/4] as recent CPUs introduce a third running state, after "user" and "system", we need a new field, "guest", in cpustat to store the time used by the CPU to run virtual CPU. Modify

The aim of these four patches is to introduce Virtual Machine time accounting. _Ingo_, as these patches modify files of the scheduler, could you have a look to them, please ? [PATCH 1/4] as recent CPUs introduce a third running state, after "user" and "system", we need a new field, "guest", in cpustat to store the time used by the CPU to run virtual CPU. Modify

Laurent Vivier wrote: > The aim of these two patches is to measure the CPU time used by a virtual > machine. All comments are welcome... I'm not sure it's the good way to do that. > > [PATCH 1/2] introduce a new field, "guest", in cpustat to store the time used by > the CPU to run virtual CPU. Modify /proc/stat to display this new field. > > [PATCH 2/2]

Laurent Vivier wrote: > The aim of these two patches is to measure the CPU time used by a virtual > machine. All comments are welcome... I'm not sure it's the good way to do that. > > [PATCH 1/2] introduce a new field, "guest", in cpustat to store the time used by > the CPU to run virtual CPU. Modify /proc/stat to display this new field. > > [PATCH 2/2]

On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > This is version 4 of the following sub-series: > > [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > [libnbd PATCH v3 10/29] lib/utils: add unit tests for async-signal-safe execvpe() > > http://mid.mail-archive.com/20230215141158.2426855-10-lersek at redhat.com >

flight 8803 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/ Regressions :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-intel 4 xen-install fail REGR. vs. 8769 test-amd64-i386-xl 4 xen-install fail REGR. vs. 8769 test-amd64-i386-pair 6 xen-install/dst_host fail REGR. vs. 8769

http://libvirt.org/html/libvirt-libvirt.html#virDomainInfo http://libvirt.org/html/libvirt-libvirt.html#virVcpuInfo Both virDomainInfo and virVcpuInfo have a nanosecond cpuTime field. How do the two related to one another? With some experiementing, it appears the virDomainInfo::cpuTime is equal to the host CPU time used by the qemu-kvm process for the domain. It also appears that the

[PATCH 3/4] modify account_system_time() to add cputime to cpustat->guest i= f we are running a VCPU. We add this cputime to cpustat->user instead of cpustat->system because this part of KVM code is in fact user code although= it is executed in the kernel. We duplicate VCPU time between guest and user to allow an unmodified "top(1)" to display correct value. A modified