From: Peter Zijlstra <peterz@infradead.org>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Paul Turner <pjt@google.com>,
Mike Galbraith <efault@gmx.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH] sched/fair: make CFS bandwidth slice per cpu group
Date: Tue, 1 May 2018 09:11:12 +0200 [thread overview]
Message-ID: <20180501071112.GD12217@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAM_iQpXPNKyCGzY3=9HaQYXCXx3hsU3a_6BsFM+6Hw--v5QZUQ@mail.gmail.com>
On Mon, Apr 30, 2018 at 01:37:16PM -0700, Cong Wang wrote:
> On Mon, Apr 30, 2018 at 12:42 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, Apr 30, 2018 at 12:29:25PM -0700, Cong Wang wrote:
> >> Currently, the sched_cfs_bandwidth_slice_us is a global setting which
> >> affects all cgroups. Different groups may want different values based
> >> on their own workload, one size doesn't fit all. The global pool filled
> >> periodically is per cgroup too, they should have the right to distribute
> >> their own quota to each local CPU with their own frequency.
> >
> > Why.. what happens? This doesn't really tell us anything.
>
> We saw tasks in a container got throttled for many times even
> when they don't apparently over-burn the CPU's. I tried to reduce
> the sched_cfs_bandwidth_slice_us from the default 5ms to 1ms,
> it solved the problem as no tasks got throttled after this change.
> This is why I want to change it.
The 1ms slice distributes time better at the cost of higher overhead,
right?
> And I don't think 1ms will be good for all containers, so in order to
> minimize the impact, I would like to keep the slice change within
> each container. This is why I propose this patch rather just
> `sysctl -w`. Do you think otherwise?
Well, I think I don't quite remember everything and a Changelog that
tells me why you want stuff in a little more detail and helps me
remember some things is a lot more useful than me having to go dig
through the code myself (which I'll invariably postpone because I'm a
busy sort of person).
> BTW, people reported a similar (if not same) issue here before:
> https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4ff1
That's not a report, that's a random person on the interweb posting
random crap. A report lands in my inbox.
next prev parent reply other threads:[~2018-05-01 7:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 19:29 [PATCH] sched/fair: make CFS bandwidth slice per cpu group Cong Wang
2018-04-30 19:42 ` Peter Zijlstra
2018-04-30 20:37 ` Cong Wang
2018-05-01 7:11 ` Peter Zijlstra [this message]
2018-05-01 18:06 ` Cong Wang
2018-05-01 0:29 ` kbuild test robot
2018-05-01 0:29 ` [RFC PATCH] sched/fair: tg_set_cfs_slice() can be static kbuild test robot
2018-05-01 0:31 ` [PATCH] sched/fair: make CFS bandwidth slice per cpu group kbuild test robot
2018-05-01 0:57 ` kbuild 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=20180501071112.GD12217@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=xiyou.wangcong@gmail.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