[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YYwd17co5iwSnDzK@lorien.usersys.redhat.com>
Date: Wed, 10 Nov 2021 14:30:31 -0500
From: Phil Auld <pauld@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Hasegawa Hitomi <hasegawa-hitomi@...itsu.com>,
Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH 2/2] sched/cputime: Fix getrusage(RUSAGE_THREAD) with
nohz_full
Hi,
On Tue, Oct 26, 2021 at 04:10:55PM +0200 Frederic Weisbecker wrote:
> getrusage(RUSAGE_THREAD) with nohz_full may return shorter utime/stime
> than the actual time.
>
> task_cputime_adjusted() snapshots utime and stime and then adjust their
> sum to match the scheduler maintained cputime.sum_exec_runtime.
> Unfortunately in nohz_full, sum_exec_runtime is only updated once per
> second in the worst case, causing a discrepancy against utime and stime
> that can be updated anytime by the reader using vtime.
>
> To fix this situation, perform an update of cputime.sum_exec_runtime
> when the cputime snapshot reports the task as actually running while
> the tick is disabled. The related overhead is then contained within the
> relevant situations.
>
> Reported-by: Hasegawa Hitomi <hasegawa-hitomi@...itsu.com>
> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> Cc: Mel Gorman <mgorman@...e.de>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Signed-off-by: Hasegawa Hitomi <hasegawa-hitomi@...itsu.com>
> ---
> include/linux/sched/cputime.h | 5 +++--
> kernel/sched/cputime.c | 12 +++++++++---
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/sched/cputime.h b/include/linux/sched/cputime.h
> index 6c9f19a33865..ce3c58286062 100644
> --- a/include/linux/sched/cputime.h
> +++ b/include/linux/sched/cputime.h
> @@ -18,15 +18,16 @@
> #endif /* CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
>
> #ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
> -extern void task_cputime(struct task_struct *t,
> +extern bool task_cputime(struct task_struct *t,
> u64 *utime, u64 *stime);
> extern u64 task_gtime(struct task_struct *t);
> #else
> -static inline void task_cputime(struct task_struct *t,
> +static inline bool task_cputime(struct task_struct *t,
> u64 *utime, u64 *stime)
> {
> *utime = t->utime;
> *stime = t->stime;
> + return false;
> }
>
> static inline u64 task_gtime(struct task_struct *t)
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 872e481d5098..9392aea1804e 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -615,7 +615,8 @@ void task_cputime_adjusted(struct task_struct *p, u64 *ut, u64 *st)
> .sum_exec_runtime = p->se.sum_exec_runtime,
> };
>
> - task_cputime(p, &cputime.utime, &cputime.stime);
> + if (task_cputime(p, &cputime.utime, &cputime.stime))
> + cputime.sum_exec_runtime = task_sched_runtime(p);
> cputime_adjust(&cputime, &p->prev_cputime, ut, st);
> }
> EXPORT_SYMBOL_GPL(task_cputime_adjusted);
> @@ -828,19 +829,21 @@ u64 task_gtime(struct task_struct *t)
> * add up the pending nohz execution time since the last
> * cputime snapshot.
> */
> -void task_cputime(struct task_struct *t, u64 *utime, u64 *stime)
> +bool task_cputime(struct task_struct *t, u64 *utime, u64 *stime)
> {
> struct vtime *vtime = &t->vtime;
> unsigned int seq;
> u64 delta;
> + int ret;
>
> if (!vtime_accounting_enabled()) {
> *utime = t->utime;
> *stime = t->stime;
> - return;
> + return false;
> }
>
> do {
> + ret = false;
> seq = read_seqcount_begin(&vtime->seqcount);
>
> *utime = t->utime;
> @@ -850,6 +853,7 @@ void task_cputime(struct task_struct *t, u64 *utime, u64 *stime)
> if (vtime->state < VTIME_SYS)
> continue;
>
> + ret = true;
> delta = vtime_delta(vtime);
>
> /*
> @@ -861,6 +865,8 @@ void task_cputime(struct task_struct *t, u64 *utime, u64 *stime)
> else
> *utime += vtime->utime + delta;
> } while (read_seqcount_retry(&vtime->seqcount, seq));
> +
> + return ret;
> }
>
> static int vtime_state_fetch(struct vtime *vtime, int cpu)
> --
> 2.25.1
>
Could someone please pick this (or, rather, these) up?
Acked-by: Phil Auld <pauld@...hat.com>
Thanks!
Phil
--
Powered by blists - more mailing lists