From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Chuyi Zhou <zhouchuyi@bytedance.com>,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
htejun@gmail.com, lizefan.x@bytedance.com, vschneid@redhat.com,
bsegall@google.com, Abel Wu <wuyun.abel@bytedance.com>
Subject: Re: [RESEND] sched/fair: Add min_ratio for cfs bandwidth_control
Date: Fri, 21 Oct 2022 08:04:13 -1000 [thread overview]
Message-ID: <Y1LfHVENWB8ZDFyr@slm.duckdns.org> (raw)
In-Reply-To: <Y1GAffm4aHCpvoBB@hirez.programming.kicks-ass.net>
Hello,
On Thu, Oct 20, 2022 at 07:08:13PM +0200, Peter Zijlstra wrote:
> > This is a bit of a bandaid. I think what we really need to do is only
> > throttling when running in userspace. In kernel space, it should just keep
> > accumulating used cycles as debt which should be paid back before userspace
> > code can run again so that we don't throttle at random places in the kernel.
>
> That's just moving the problem. But yeah; perhaps. Starving random
> userspace is less of a problem I suppose.
Given that our primary mean of guaranteeing forward progress is the fact
that the system runs out of other things to do when there are severe
priority inversions, I don't think we can safely give control of throttling
something running in the kernel to userspace.
IO control takes a similar approach with shared IOs which can have
system-wide impacts and it's been working out pretty well. While some may go
over the limit briefly, it's not that difficult to remain true to the
intended configuration over time.
The only problem is the cases where userspace can cause a large amount of
forced consumptions (e.g. for IOs, creating a lot of metadata updates
without doing anything else), but even in the unlikely case similar problem
exists for CPU, it's pretty easy to add specific control mechanisms around
those (e.g. sth along the style of might_resched()).
So, yeah, I think this is the actual solution.
Thanks.
--
tejun
prev parent reply other threads:[~2022-10-21 18:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 3:15 [RESEND] sched/fair: Add min_ratio for cfs bandwidth_control Chuyi Zhou
2022-10-19 21:01 ` Benjamin Segall
2022-10-20 9:14 ` [External] " Chuyi Zhou
2022-10-19 21:21 ` Tejun Heo
2022-10-20 6:35 ` Chuyi Zhou
2022-10-20 17:08 ` Peter Zijlstra
2022-10-21 18:04 ` Tejun Heo [this message]
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=Y1LfHVENWB8ZDFyr@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bsegall@google.com \
--cc=htejun@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wuyun.abel@bytedance.com \
--cc=zhouchuyi@bytedance.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