From: Mike Galbraith <efault-Mmb7MZpHnFY@public.gmane.org>
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Peter Zijlstra
<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Subject: Re: RFC: documentation of the autogroup feature [v2]
Date: Fri, 25 Nov 2016 14:02:53 +0100 [thread overview]
Message-ID: <1480078973.4075.58.camel@gmx.de> (raw)
In-Reply-To: <c5a9acd3-6b60-192c-312e-2777f2d537c2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 2016-11-24 at 22:41 +0100, Michael Kerrisk (man-pages) wrote:
> Suppose that there are two autogroups competing for the same
> CPU. The first group contains ten CPU-bound processes from a
> kernel build started with make -j10. The other contains a sin‐
> gle CPU-bound process: a video player. The effect of auto‐
> grouping is that the two groups will each receive half of the
> CPU cycles. That is, the video player will receive 50% of the
> CPU cycles, rather just 9% of the cycles, which would likely
> lead to degraded video playback. Or to put things another way:
> an autogroup that contains a large number of CPU-bound pro‐
> cesses does not end up overwhelming the CPU at the expense of
> the other jobs on the system.
I'd say something more wishy-washy here, like cycles are distributed
fairly across groups and leave it at that, as your detailed example is
incorrect due to SMP fairness (which I don't like much because [very
unlikely] worst case scenario renders a box sized group incapable of
utilizing more that a single CPU total). For example, if a group of
NR_CPUS size competes with a singleton, load balancing will try to give
the singleton a full CPU of its very own. If groups intersect for
whatever reason on say my quad lappy, distribution is 80/20 in favor of
the singleton.
> ┌─────────────────────────────────────────────────────┐
> │FIXME │
> ├─────────────────────────────────────────────────────┤
> │How do the nice value of a process and the nice │
> │value of an autogroup interact? Which has priority? │
> │ │
> │It *appears* that the autogroup nice value is used │
> │for CPU distribution between task groups, and that │
> │the process nice value has no effect there. (I.e., │
> │suppose two autogroups each contain a CPU-bound │
> │process, with one process having nice==0 and the │
> │other having nice==19. It appears that they each │
> │get 50% of the CPU.) It appears that the process │
> │nice value has effect only with respect to schedul‐ │
> │ing relative to other processes in the *same* auto‐ │
> │group. Is this correct? │
> └─────────────────────────────────────────────────────┘
Yup, entity nice level affects distribution among peer entities.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mike Galbraith <efault@gmx.de>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@kernel.org>,
linux-man <linux-man@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: RFC: documentation of the autogroup feature [v2]
Date: Fri, 25 Nov 2016 14:02:53 +0100 [thread overview]
Message-ID: <1480078973.4075.58.camel@gmx.de> (raw)
In-Reply-To: <c5a9acd3-6b60-192c-312e-2777f2d537c2@gmail.com>
On Thu, 2016-11-24 at 22:41 +0100, Michael Kerrisk (man-pages) wrote:
> Suppose that there are two autogroups competing for the same
> CPU. The first group contains ten CPU-bound processes from a
> kernel build started with make -j10. The other contains a sin‐
> gle CPU-bound process: a video player. The effect of auto‐
> grouping is that the two groups will each receive half of the
> CPU cycles. That is, the video player will receive 50% of the
> CPU cycles, rather just 9% of the cycles, which would likely
> lead to degraded video playback. Or to put things another way:
> an autogroup that contains a large number of CPU-bound pro‐
> cesses does not end up overwhelming the CPU at the expense of
> the other jobs on the system.
I'd say something more wishy-washy here, like cycles are distributed
fairly across groups and leave it at that, as your detailed example is
incorrect due to SMP fairness (which I don't like much because [very
unlikely] worst case scenario renders a box sized group incapable of
utilizing more that a single CPU total). For example, if a group of
NR_CPUS size competes with a singleton, load balancing will try to give
the singleton a full CPU of its very own. If groups intersect for
whatever reason on say my quad lappy, distribution is 80/20 in favor of
the singleton.
> ┌─────────────────────────────────────────────────────┐
> │FIXME │
> ├─────────────────────────────────────────────────────┤
> │How do the nice value of a process and the nice │
> │value of an autogroup interact? Which has priority? │
> │ │
> │It *appears* that the autogroup nice value is used │
> │for CPU distribution between task groups, and that │
> │the process nice value has no effect there. (I.e., │
> │suppose two autogroups each contain a CPU-bound │
> │process, with one process having nice==0 and the │
> │other having nice==19. It appears that they each │
> │get 50% of the CPU.) It appears that the process │
> │nice value has effect only with respect to schedul‐ │
> │ing relative to other processes in the *same* auto‐ │
> │group. Is this correct? │
> └─────────────────────────────────────────────────────┘
Yup, entity nice level affects distribution among peer entities.
-Mike
next prev parent reply other threads:[~2016-11-25 13:02 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-22 15:59 RFC: documentation of the autogroup feature Michael Kerrisk (man-pages)
2016-11-23 10:33 ` [patch] sched/autogroup: Fix 64bit kernel nice adjustment Mike Galbraith
[not found] ` <1479897217.4306.6.camel-Mmb7MZpHnFY@public.gmane.org>
2016-11-23 13:47 ` Michael Kerrisk (man-pages)
2016-11-23 13:47 ` Michael Kerrisk (man-pages)
[not found] ` <d21cf0b2-5c62-5a49-8758-58793c454cc2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-23 14:12 ` Mike Galbraith
2016-11-23 14:12 ` Mike Galbraith
2016-11-23 14:20 ` Michael Kerrisk (man-pages)
[not found] ` <34cea28b-c8c7-31e3-e920-90f113d22abe-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-23 15:55 ` Mike Galbraith
2016-11-23 15:55 ` Mike Galbraith
2016-11-24 6:24 ` [tip:sched/urgent] sched/autogroup: Fix 64-bit kernel nice level adjustment tip-bot for Mike Galbraith
2016-11-24 6:24 ` tip-bot for Mike Galbraith
2016-11-23 11:39 ` RFC: documentation of the autogroup feature Mike Galbraith
[not found] ` <1479901185.4306.38.camel-Mmb7MZpHnFY@public.gmane.org>
2016-11-23 13:54 ` Michael Kerrisk (man-pages)
2016-11-23 13:54 ` Michael Kerrisk (man-pages)
[not found] ` <327586fa-4672-d070-0ded-850654586273-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-23 15:33 ` Mike Galbraith
2016-11-23 15:33 ` Mike Galbraith
[not found] ` <1479915229.4306.106.camel-Mmb7MZpHnFY@public.gmane.org>
2016-11-23 16:04 ` Michael Kerrisk (man-pages)
2016-11-23 16:04 ` Michael Kerrisk (man-pages)
2016-11-23 17:11 ` Mike Galbraith
2016-11-24 21:41 ` RFC: documentation of the autogroup feature [v2] Michael Kerrisk (man-pages)
2016-11-25 12:52 ` Afzal Mohammed
2016-11-25 13:04 ` Michael Kerrisk (man-pages)
2016-11-25 13:04 ` Michael Kerrisk (man-pages)
[not found] ` <c5a9acd3-6b60-192c-312e-2777f2d537c2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 13:02 ` Mike Galbraith [this message]
2016-11-25 13:02 ` Mike Galbraith
2016-11-25 15:04 ` Michael Kerrisk (man-pages)
[not found] ` <ca16c155-22be-df06-4f2d-4337b72381de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 15:48 ` Michael Kerrisk (man-pages)
2016-11-25 15:48 ` Michael Kerrisk (man-pages)
2016-11-25 16:04 ` Peter Zijlstra
2016-11-25 16:04 ` Peter Zijlstra
[not found] ` <20161125160456.GP3092-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-11-25 16:13 ` Peter Zijlstra
2016-11-25 16:13 ` Peter Zijlstra
2016-11-25 16:33 ` Michael Kerrisk (man-pages)
2016-11-25 16:33 ` Michael Kerrisk (man-pages)
[not found] ` <c0f61369-9601-0c90-8b85-61e75e4f4e82-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 22:48 ` Peter Zijlstra
2016-11-25 22:48 ` Peter Zijlstra
2016-11-25 15:51 ` Mike Galbraith
[not found] ` <1480089063.4075.80.camel-Mmb7MZpHnFY@public.gmane.org>
2016-11-25 16:08 ` Michael Kerrisk (man-pages)
2016-11-25 16:08 ` Michael Kerrisk (man-pages)
[not found] ` <d3d491d3-0770-d017-4f3c-43d88346835c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 16:18 ` Peter Zijlstra
2016-11-25 16:18 ` Peter Zijlstra
[not found] ` <20161125161810.GR3092-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-11-25 16:34 ` Michael Kerrisk (man-pages)
2016-11-25 16:34 ` Michael Kerrisk (man-pages)
[not found] ` <2cc53b76-668b-edf1-6aa7-e6cb5a9801e1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 20:54 ` Michael Kerrisk (man-pages)
2016-11-25 20:54 ` Michael Kerrisk (man-pages)
[not found] ` <af075c46-152a-0392-d33f-c7956d3c8a0b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-25 21:49 ` Peter Zijlstra
2016-11-25 21:49 ` Peter Zijlstra
[not found] ` <20161125214936.GB3045-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2016-11-29 7:43 ` Michael Kerrisk (man-pages)
2016-11-29 7:43 ` Michael Kerrisk (man-pages)
[not found] ` <755aba1b-9bf4-0277-0628-b27e725ee2f9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-29 11:46 ` Peter Zijlstra
2016-11-29 11:46 ` Peter Zijlstra
[not found] ` <20161129114629.GG3092-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-11-29 13:44 ` Michael Kerrisk (man-pages)
2016-11-29 13:44 ` Michael Kerrisk (man-pages)
2016-11-23 16:05 ` RFC: documentation of the autogroup feature Michael Kerrisk (man-pages)
2016-11-23 16:05 ` Michael Kerrisk (man-pages)
[not found] ` <fc3ae5c6-5a50-e991-71fd-b544096bbe5c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-23 17:19 ` Mike Galbraith
2016-11-23 17:19 ` Mike Galbraith
[not found] ` <1479921544.4306.157.camel-Mmb7MZpHnFY@public.gmane.org>
2016-11-23 22:12 ` Michael Kerrisk (man-pages)
2016-11-23 22:12 ` Michael Kerrisk (man-pages)
2016-11-27 21:13 ` Michael Kerrisk (man-pages)
2016-11-27 21:13 ` Michael Kerrisk (man-pages)
[not found] ` <8614679c-b1d3-3b35-193d-2ab6eac45aff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-28 1:46 ` Mike Galbraith
2016-11-28 1:46 ` Mike Galbraith
[not found] ` <1127218a-dd9b-71a8-845d-3a83969632fc@gmail.com>
[not found] ` <1127218a-dd9b-71a8-845d-3a83969632fc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-11-29 9:10 ` Michael Kerrisk (man-pages)
2016-11-29 9:10 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkiLafr7KJNAo+_kwKQB7ueO-oontNL_FQrGtqitmJpEDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-11-29 13:46 ` Mike Galbraith
2016-11-29 13:46 ` Mike Galbraith
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=1480078973.4075.58.camel@gmx.de \
--to=efault-mmb7mzphnfy@public.gmane.org \
--cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.