From: Peter Zijlstra <peterz@infradead.org>
To: Paul Turner <pjt@google.com>
Cc: Xi Wang <xii@google.com>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Josh Don <joshdon@google.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] sched: watchdog: Touch kernel watchdog in sched code
Date: Fri, 6 Mar 2020 09:40:39 +0100 [thread overview]
Message-ID: <20200306084039.GC12561@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAPM31RJdNtxmOi2eeRYFyvRKG9nofhqZfPgZGA5U7u8uZ2WXwA@mail.gmail.com>
On Thu, Mar 05, 2020 at 02:11:49PM -0800, Paul Turner wrote:
> The goal is to improve jitter since we're constantly periodically
> preempting other classes to run the watchdog. Even on a single CPU
> this is measurable as jitter in the us range. But, what increases the
> motivation is this disruption has been recently magnified by CPU
> "gifts" which require evicting the whole core when one of the siblings
> schedules one of these watchdog threads.
>
> The majority outcome being asserted here is that we could actually
> exercise pick_next_task if required -- there are other potential
> things this will catch, but they are much more braindead generally
> speaking (e.g. a bug in pick_next_task itself).
I still utterly hate what the patch does though; there is no way I'll
have watchdog code hook in the scheduler like this. That's just asking
for trouble.
Why isn't it sufficient to sample the existing context switch counters
from the watchdog? And why can't we fix that?
next prev parent reply other threads:[~2020-03-06 8:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 21:39 Xi Wang
2020-03-05 3:11 ` Steven Rostedt
2020-03-05 7:57 ` Peter Zijlstra
2020-03-05 18:07 ` Thomas Gleixner
2020-03-05 21:41 ` Xi Wang
2020-03-05 22:07 ` Paul Turner
[not found] ` <CAOBoifgHNag0P33PKg81iNoCjxenJHfBZG-t-8aEkr_Tjf7o_w@mail.gmail.com>
2020-03-06 8:28 ` Peter Zijlstra
2020-03-05 22:11 ` Paul Turner
2020-03-06 8:40 ` Peter Zijlstra [this message]
2020-03-06 22:34 ` Xi Wang
2020-10-05 11:19 ` Peter Zijlstra
2020-10-06 2:21 ` Xi Wang
2020-03-10 8:43 ` [sched] db8e976e4a: will-it-scale.per_process_ops 15.8% improvement kernel test robot
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=20200306084039.GC12561@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=xii@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®