From: Ivan Babrou <firstname.lastname@example.org> To: Johannes Weiner <email@example.com> Cc: linux-kernel <firstname.lastname@example.org>, kernel-team <email@example.com>, Ingo Molnar <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Juri Lelli <firstname.lastname@example.org>, Vincent Guittot <email@example.com>, Dietmar Eggemann <firstname.lastname@example.org>, Steven Rostedt <email@example.com>, Ben Segall <firstname.lastname@example.org>, Mel Gorman <email@example.com> Subject: Re: Lower than expected CPU pressure in PSI Date: Thu, 16 Jan 2020 12:24:47 -0800 Message-ID: <CABWYdi3BrQHaM_Np81W8f=EFU09cqqJARbywEvhq_XWoDqrBPw@mail.gmail.com> (raw) In-Reply-To: <20200115165543.GA47772@cmpxchg.org> This definitely helps! It would be nice to add this as a section here: * https://www.kernel.org/doc/html/latest/accounting/psi.html On Wed, Jan 15, 2020 at 8:55 AM Johannes Weiner <firstname.lastname@example.org> wrote: > > On Fri, Jan 10, 2020 at 11:28:32AM -0800, Ivan Babrou wrote: > > I applied the patch on top of 5.5.0-rc3 and it's definitely better > > now, both competing cgroups report 500ms/s delay. Feel free to add > > Tested-by from me. > > Thanks, Ivan! > > > I'm still seeing /unified/system.slice at 385ms/s and /unified.slice > > at 372ms/s, do you have an explanation for that part? Maybe it's > > totally reasonable, but warrants a patch for documentation. > > Yes, this is a combination of CPU pinning and how pressure is > calculated in SMP systems. > > The stall times are defined as lost compute potential - which scales > with the number of concurrent threads - normalized to wallclock > time. See the "Multiple CPUs" section in kernel/sched/psi.c. > > By restricting the CPUs in system.slice, there is less compute > available in that group than in the parent, which means that the > relative loss of potential can be higher. > > It's a bit unintuitive because most cgroup metrics are plain numbers > that add up to bigger numbers as you go up the tree. If we exported > both the numerator (waste) and denominator (compute potential) here, > the numbers would act more conventionally, with parent numbers always > bigger than the child's. But because pressure is normalized to > wallclock time, you only see the ratio at each level, and that can > shrink as you go up the tree if lower levels are CPU-constrained. > > We could have exported both numbers, but for most usecases that would > be more confusing than helpful. And in practice it's the ratio that > really matters: the pressure in the leaf cgroups is high due to the > CPU restriction; but when you go higher up the tree and look at not > just the pinned tasks, but also include tasks in other groups that > have more CPUs available to them, the aggregate productivity at that > level *is* actually higher. > > I hope that helps!
next prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-08 19:47 Ivan Babrou 2020-01-09 16:16 ` Johannes Weiner 2020-01-10 19:28 ` Ivan Babrou 2020-01-15 16:55 ` Johannes Weiner 2020-01-16 20:24 ` Ivan Babrou [this message] 2020-01-09 16:23 ` Johannes Weiner
Reply instructions: You may reply publically 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='CABWYdi3BrQHaM_Np81W8f=EFU09cqqJARbywEvhq_XWoDqrBPw@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git