From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Wanpeng Li <wanpengli@tencent.com>, Pavel Machek <pavel@ucw.cz>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Thomas Gleixner <tglx@linutronix.de>,
Yauheni Kaliuta <yauheni.kaliuta@redhat.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH 3/9] sched/vtime: Handle nice updates under vtime
Date: Fri, 15 Nov 2019 11:16:48 +0100 [thread overview]
Message-ID: <20191115101648.GC4131@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191106030807.31091-4-frederic@kernel.org>
On Wed, Nov 06, 2019 at 04:08:01AM +0100, Frederic Weisbecker wrote:
> The cputime niceness is determined while checking the target's nice value
> at cputime accounting time. Under vtime this happens on context switches,
> user exit and guest exit. But nice value updates while the target is
> running are not taken into account.
>
> So if a task runs tickless for 10 seconds in userspace but it has been
> reniced after 5 seconds from -1 (not nice) to 1 (nice), on user exit
> vtime will account the whole 10 seconds as CPUTIME_NICE because it only
> sees the latest nice value at accounting time which is 1 here. Yet it's
> wrong, 5 seconds should be accounted as CPUTIME_USER and 5 seconds as
> CPUTIME_NICE.
>
> In order to solve this, we now cover nice updates withing three cases:
>
> * If the nice updater is the current task, although we are in kernel
> mode there can be pending user or guest time in the cache to flush
> under the prior nice state. Account these if any. Also toggle the
> vtime nice flag for further user/guest cputime accounting.
>
> * If the target runs on a different CPU, we interrupt it with an IPI to
> update the vtime state in place. If the task is running in user or
> guest, the pending cputime is accounted under the prior nice state.
> Then the vtime nice flag is toggled for further user/guest cputime
> accounting.
But but but, I thought the idea was to _never_ send interrupts to
NOHZ_FULL cpus ?!?
next prev parent reply other threads:[~2019-11-15 10:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 3:07 [PATCH 0/9] sched/nohz: Make the rest of kcpustat vtime aware Frederic Weisbecker
2019-11-06 3:07 ` [PATCH 1/9] sched/cputime: Allow to pass cputime index on user/guest accounting Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 2/9] sched/cputime: Standardize the kcpustat index based accounting functions Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 3/9] sched/vtime: Handle nice updates under vtime Frederic Weisbecker
2019-11-15 10:14 ` Peter Zijlstra
2019-11-15 10:16 ` Peter Zijlstra [this message]
2019-11-15 10:18 ` Peter Zijlstra
2019-11-15 15:27 ` Frederic Weisbecker
2019-11-18 13:04 ` Peter Zijlstra
2019-11-06 3:08 ` [PATCH 4/9] sched/cputime: Support other fields on kcpustat_field() Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 5/9] sched/vtime: Bring all-in-one kcpustat accessor for vtime fields Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 6/9] procfs: Use all-in-one vtime aware kcpustat accessor Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 7/9] cpufreq: Use vtime aware kcpustat accessors for user time Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 8/9] leds: Use all-in-one vtime aware kcpustat accessor Frederic Weisbecker
2019-11-06 3:08 ` [PATCH 9/9] rackmeter: Use " Frederic Weisbecker
2019-11-14 15:25 ` [PATCH 0/9] sched/nohz: Make the rest of kcpustat vtime aware Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191115101648.GC4131@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=frederic@kernel.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pavel@ucw.cz \
--cc=riel@surriel.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.org \
--cc=wanpengli@tencent.com \
--cc=yauheni.kaliuta@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.