Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1600535

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

From Mike Galbraith <efault@gmx.de>
Newsgroups linux.kernel
Subject Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode
Date 2017-03-14 16:00 +0100
Message-ID <tkW5A-1Ad-39@gated-at.bofh.it> (permalink)
References (6 earlier) <t9nEe-6Co-29@gated-at.bofh.it> <t9UA9-1Yw-3@gated-at.bofh.it> <t9Wsh-3fy-3@gated-at.bofh.it> <tahGq-7NL-9@gated-at.bofh.it> <tkDPj-58M-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, 2017-03-13 at 15:26 -0400, Tejun Heo wrote:
> Hello, Mike.
> 
> Sorry about the long delay.
> 
> On Mon, Feb 13, 2017 at 06:45:07AM +0100, Mike Galbraith wrote:
> > > > So, as long as the depth stays reasonable (single digit or lower),
> > > > what we try to do is keeping tree traversal operations aggregated or
> > > > located on slow paths.  There still are places that this overhead
> > > > shows up (e.g. the block controllers aren't too optimized) but it
> > > > isn't particularly difficult to make a handful of layers not matter at
> > > > all.
> > > 
> > > A handful of cpu bean counting layers stings considerably.
> 
> Hmm... yeah, I was trying to think about ways to avoid full scheduling
> overhead at each layer (the scheduler does a lot per each layer of
> scheduling) but don't think it's possible to circumvent that without
> introducing a whole lot of scheduling artifacts.

Yup.

> In a lot of workloads, the added overhead from several layers of CPU
> controllers doesn't seem to get in the way too much (most threads do
> something other than scheduling after all).

Sure, don't schedule a lot, it doesn't hurt much, but there are plenty
of loads that routinely do schedule a LOT, and there it matters a LOT..
which is why network benchmarks tend to be severely allergic to
scheduler lard.

>   The only major issue that
> we're seeing in the fleet is the cgroup iteration in idle rebalancing
> code pushing up the scheduling latency too much but that's a different
> issue.

Hm, I would suspect PELT to be the culprit there.  It helps smooth out
load balancing, but will stack "skinny looking" tasks.

	-Mike

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode Mike Galbraith <efault@gmx.de> - 2017-03-14 16:00 +0100

csiph-web