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


Groups > linux.kernel > #1302755

Re: [RFD] CAT user space interface revisited

From Tejun Heo <tj@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFD] CAT user space interface revisited
Date 2016-01-06 14:20 +0100
Message-ID <qNWam-1Ck-19@gated-at.bofh.it> (permalink)
References (4 earlier) <qLR58-8w5-11@gated-at.bofh.it> <qLU2Z-1SE-9@gated-at.bofh.it> <qNh7d-6vZ-23@gated-at.bofh.it> <qNJ3s-1f2-13@gated-at.bofh.it> <qNVHk-1aT-15@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello, Marcelo.

On Wed, Jan 06, 2016 at 10:46:15AM -0200, Marcelo Tosatti wrote:
> Well, i suppose cgroups has facilities to handle this? That is, what is
> required is:

No, it doesn't.

> On task creation, move the new task to a particular cgroup, based on
> some visible characteristic of the task: (process name matching OR explicit
> kernel thread creator specification OR ...).

cgroup's primary goal is resource tracking and control.  For userland
processes, following fork / clone is enough; however, for a lot of
kthread tasks, task isn't even the right unit.  e.g. Think of CPU
cycles spent on packet reception, spawning per-cgroup kthreads to
handle packet rx separately isn't a realistic option.  The granularity
needs to be higher.  Except for a handful of cases, this pattern
holds.  Another example is IO resources spent during journal write.
Most of in-kernel resource tracking can't be split per-kthread.

While assigning kthreads to specific cgroups can be useful for a few
specific use cases, in terms of in-kernel resource tracking, it's more
of a distraction.

Please stop using cgroup for random task grouping.  Supporting the
level of flexibility to support arbitrary grouping gets in the way of
implementing proper resource control.  You won't be happy because
cgroup's rules get in the way and cgroup won't be happy because your
random stuff gets in the way of proper resource control.

Thomas's proposal obviously works better for the task at hand.  Maybe
there's something which can be extracted out of cgroup and shared for
task group tracking, if nothing else, hooks and synchronization, but
please don't tack it on top of cgroup when it doesn't really fit the
hierarchical resource distribution model.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


Thread

Re: [RFD] CAT user space interface revisited Marcelo Tosatti <mtosatti@redhat.com> - 2016-01-04 18:30 +0100
  Re: [RFD] CAT user space interface revisited Marcelo Tosatti <mtosatti@redhat.com> - 2016-01-04 18:50 +0100
  Re: [RFD] CAT user space interface revisited Thomas Gleixner <tglx@linutronix.de> - 2016-01-06 00:20 +0100
    Re: [RFD] CAT user space interface revisited Marcelo Tosatti <mtosatti@redhat.com> - 2016-01-06 13:50 +0100
      Re: [RFD] CAT user space interface revisited Tejun Heo <tj@kernel.org> - 2016-01-06 14:20 +0100
    Re: [RFD] CAT user space interface revisited Thomas Gleixner <tglx@linutronix.de> - 2016-01-08 21:30 +0100

csiph-web