From: Peter Zijlstra <peterz@infradead.org> To: Andy Lutomirski <luto@amacapital.net> Cc: Ingo Molnar <mingo@redhat.com>, Mike Galbraith <umgwanakikbuti@gmail.com>, kernel-team@fb.com, Andrew Morton <akpm@linux-foundation.org>, "open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>, Paul Turner <pjt@google.com>, Li Zefan <lizefan@huawei.com>, Linux API <linux-api@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, Linus Torvalds <torvalds@linux-foundation.org> Subject: Re: [Documentation] State of CPU controller in cgroup v2 Date: Sat, 17 Sep 2016 03:47:29 +0200 [thread overview] Message-ID: <20160917014729.GN5016@twins.programming.kicks-ass.net> (raw) In-Reply-To: <CALCETrVMw4Nd-QZER9qzOzRte5s48WrUaM8ZZzkY_g3B6s+5Ow@mail.gmail.com> On Fri, Sep 16, 2016 at 11:19:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 16, 2016 at 9:50 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > {1,2} {3,4} {5} seem exclusive, did I miss something? (other than that 5 > > cpu parts are 'rare'). > > There's no overlap, so they're logically exclusive, but it avoids > needing the "cpu_exclusive" parameter. I'd need to double check, but I don't think you _need_ that. That's more for enforcing nobody else steals your CPUs and 'accidentally' creates overlaps. But if you configure it right, non-overlap should be enough. That is, generate_sched_domains() only uses cpusets_overlap() which is cpumask_intersects(). Then again, it is almost 4am, so who knows. > > So there's a problem with sticking kernel threads (and esp. kthreadd) > > into !root groups. For example if you place it in a cpuset that doesn't > > have all cpus, then binding your shiny new kthread to a cpu will fail. > > > > You can fix that of course, and we used to do exactly that, but we kept > > running into 'fun' cases like that. > > Blech. But may this *should* have that effect. I'm sick of random > kernel crap being scheduled on my RT CPUs and on the CPUs that I > intend to be kept forcibly idle. Hehe, so ideally those threads don't do anything unless the tasks running on those CPUs explicitly ask for it. If you find any of the CPU-bound kernel tasks do work that is unrelated to the tasks running on that CPU, we should certainly look into it. Personally I'm not much bothered by idle threads sitting about.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, kernel-team-b10kYP2dOMg@public.gmane.org, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, "open list:CONTROL GROUP (CGROUP)" <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Paul Turner <pjt-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Subject: Re: [Documentation] State of CPU controller in cgroup v2 Date: Sat, 17 Sep 2016 03:47:29 +0200 [thread overview] Message-ID: <20160917014729.GN5016@twins.programming.kicks-ass.net> (raw) In-Reply-To: <CALCETrVMw4Nd-QZER9qzOzRte5s48WrUaM8ZZzkY_g3B6s+5Ow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Fri, Sep 16, 2016 at 11:19:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 16, 2016 at 9:50 AM, Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote: > > {1,2} {3,4} {5} seem exclusive, did I miss something? (other than that 5 > > cpu parts are 'rare'). > > There's no overlap, so they're logically exclusive, but it avoids > needing the "cpu_exclusive" parameter. I'd need to double check, but I don't think you _need_ that. That's more for enforcing nobody else steals your CPUs and 'accidentally' creates overlaps. But if you configure it right, non-overlap should be enough. That is, generate_sched_domains() only uses cpusets_overlap() which is cpumask_intersects(). Then again, it is almost 4am, so who knows. > > So there's a problem with sticking kernel threads (and esp. kthreadd) > > into !root groups. For example if you place it in a cpuset that doesn't > > have all cpus, then binding your shiny new kthread to a cpu will fail. > > > > You can fix that of course, and we used to do exactly that, but we kept > > running into 'fun' cases like that. > > Blech. But may this *should* have that effect. I'm sick of random > kernel crap being scheduled on my RT CPUs and on the CPUs that I > intend to be kept forcibly idle. Hehe, so ideally those threads don't do anything unless the tasks running on those CPUs explicitly ask for it. If you find any of the CPU-bound kernel tasks do work that is unrelated to the tasks running on that CPU, we should certainly look into it. Personally I'm not much bothered by idle threads sitting about.
next prev parent reply other threads:[~2016-09-17 1:47 UTC|newest] Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-05 17:07 [Documentation] State of CPU controller in cgroup v2 Tejun Heo 2016-08-05 17:07 ` Tejun Heo 2016-08-05 17:09 ` [PATCH 1/2] sched: Misc preps for cgroup unified hierarchy interface Tejun Heo 2016-08-05 17:09 ` Tejun Heo 2016-08-05 17:09 ` [PATCH 2/2] sched: Implement interface for cgroup unified hierarchy Tejun Heo 2016-08-05 17:09 ` Tejun Heo 2016-08-06 9:04 ` [Documentation] State of CPU controller in cgroup v2 Mike Galbraith 2016-08-06 9:04 ` Mike Galbraith 2016-08-10 22:09 ` Johannes Weiner 2016-08-10 22:09 ` Johannes Weiner 2016-08-11 6:25 ` Mike Galbraith 2016-08-11 6:25 ` Mike Galbraith 2016-08-12 22:17 ` Johannes Weiner 2016-08-12 22:17 ` Johannes Weiner 2016-08-13 5:08 ` Mike Galbraith 2016-08-13 5:08 ` Mike Galbraith 2016-08-16 14:07 ` Peter Zijlstra 2016-08-16 14:07 ` Peter Zijlstra 2016-08-16 14:58 ` Chris Mason 2016-08-16 14:58 ` Chris Mason 2016-08-16 16:30 ` Johannes Weiner 2016-08-16 16:30 ` Johannes Weiner 2016-08-17 9:33 ` Mike Galbraith 2016-08-16 21:59 ` Tejun Heo 2016-08-16 21:59 ` Tejun Heo 2016-08-17 20:18 ` Andy Lutomirski 2016-08-20 15:56 ` Tejun Heo 2016-08-20 15:56 ` Tejun Heo 2016-08-20 18:45 ` Andy Lutomirski 2016-08-29 22:20 ` Tejun Heo 2016-08-29 22:20 ` Tejun Heo 2016-08-31 3:42 ` Andy Lutomirski 2016-08-31 3:42 ` Andy Lutomirski 2016-08-31 17:32 ` Tejun Heo 2016-08-31 19:11 ` Andy Lutomirski 2016-08-31 19:11 ` Andy Lutomirski 2016-08-31 21:07 ` Tejun Heo 2016-08-31 21:07 ` Tejun Heo 2016-08-31 21:46 ` Andy Lutomirski 2016-09-03 22:05 ` Tejun Heo 2016-09-03 22:05 ` Tejun Heo 2016-09-05 17:37 ` Andy Lutomirski 2016-09-06 10:29 ` Peter Zijlstra 2016-09-06 10:29 ` Peter Zijlstra 2016-10-04 14:47 ` Tejun Heo 2016-10-05 8:07 ` Peter Zijlstra 2016-10-05 8:07 ` Peter Zijlstra 2016-09-09 22:57 ` Tejun Heo 2016-09-10 8:54 ` Mike Galbraith 2016-09-10 8:54 ` Mike Galbraith 2016-09-10 10:08 ` Mike Galbraith 2016-09-10 10:08 ` Mike Galbraith 2016-09-30 9:06 ` Tejun Heo 2016-09-30 9:06 ` Tejun Heo 2016-09-30 14:53 ` Mike Galbraith 2016-09-30 14:53 ` Mike Galbraith 2016-09-12 15:20 ` Austin S. Hemmelgarn 2016-09-12 15:20 ` Austin S. Hemmelgarn 2016-09-19 21:34 ` Tejun Heo 2016-09-19 21:34 ` Tejun Heo [not found] ` <CALCETrUhpPQdyZ-6WRjdB+iLbpGBduRZMWXQtCuS+R7Cq7rygg@mail.gmail.com> 2016-09-14 20:00 ` Tejun Heo 2016-09-15 20:08 ` Andy Lutomirski 2016-09-15 20:08 ` Andy Lutomirski 2016-09-16 7:51 ` Peter Zijlstra 2016-09-16 7:51 ` Peter Zijlstra 2016-09-16 15:12 ` Andy Lutomirski 2016-09-16 15:12 ` Andy Lutomirski 2016-09-16 16:19 ` Peter Zijlstra 2016-09-16 16:19 ` Peter Zijlstra 2016-09-16 16:29 ` Andy Lutomirski 2016-09-16 16:29 ` Andy Lutomirski 2016-09-16 16:50 ` Peter Zijlstra 2016-09-16 16:50 ` Peter Zijlstra 2016-09-16 18:19 ` Andy Lutomirski 2016-09-16 18:19 ` Andy Lutomirski 2016-09-17 1:47 ` Peter Zijlstra [this message] 2016-09-17 1:47 ` Peter Zijlstra 2016-09-19 21:53 ` Tejun Heo 2016-09-19 21:53 ` Tejun Heo 2016-08-31 19:57 ` Andy Lutomirski 2016-08-31 19:57 ` Andy Lutomirski 2016-08-22 10:12 ` Mike Galbraith 2016-08-22 10:12 ` Mike Galbraith 2016-08-21 5:34 ` James Bottomley 2016-08-21 5:34 ` James Bottomley 2016-08-29 22:35 ` Tejun Heo 2016-08-29 22:35 ` Tejun Heo
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=20160917014729.GN5016@twins.programming.kicks-ass.net \ --to=peterz@infradead.org \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=hannes@cmpxchg.org \ --cc=kernel-team@fb.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan@huawei.com \ --cc=luto@amacapital.net \ --cc=mingo@redhat.com \ --cc=pjt@google.com \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=umgwanakikbuti@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: linkBe 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.