archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <>
To: Daniel Jordan <>
Subject: Re: [RFC v2 0/5] cgroup-aware unbound workqueues
Date: Tue, 11 Jun 2019 12:55:49 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello, Daniel.

On Wed, Jun 05, 2019 at 11:32:29AM -0400, Daniel Jordan wrote:
> Sure, quoting from the last ktask post:
>   A single CPU can spend an excessive amount of time in the kernel operating
>   on large amounts of data.  Often these situations arise during initialization-
>   and destruction-related tasks, where the data involved scales with system size.
>   These long-running jobs can slow startup and shutdown of applications and the
>   system itself while extra CPUs sit idle.
>   To ensure that applications and the kernel continue to perform well as core
>   counts and memory sizes increase, harness these idle CPUs to complete such jobs
>   more quickly.
>   ktask is a generic framework for parallelizing CPU-intensive work in the
>   kernel.  The API is generic enough to add concurrency to many different kinds
>   of tasks--for example, zeroing a range of pages or evicting a list of
>   inodes--and aims to save its clients the trouble of splitting up the work,
>   choosing the number of threads to use, maintaining an efficient concurrency
>   level, starting these threads, and load balancing the work between them.

Yeah, that rings a bell.

> > For memory and io, we're generally going for remote charging, where a
> > kthread explicitly says who the specific io or allocation is for,
> > combined with selective back-charging, where the resource is charged
> > and consumed unconditionally even if that would put the usage above
> > the current limits temporarily.  From what I've been seeing recently,
> > combination of the two give us really good control quality without
> > being too invasive across the stack.
> Yes, for memory I actually use remote charging.  In patch 3 the worker's
> current->active_memcg field is changed to match that of the cgroup associated
> with the work.

I see.

> > CPU doesn't have a backcharging mechanism yet and depending on the use
> > case, we *might* need to put kthreads in different cgroups.  However,
> > such use cases might not be that abundant and there may be gotaches
> > which require them to be force-executed and back-charged (e.g. fs
> > compression from global reclaim).
> The CPU-intensiveness of these works is one of the reasons for actually putting
> the workers through the migration path.  I don't know of a way to get the
> workers to respect the cpu controller (and even cpuset for that matter) without
> doing that.

So, I still think it'd likely be better to go back-charging route than
actually putting kworkers in non-root cgroups.  That's gonna be way
cheaper, simpler and makes avoiding inadvertent priority inversions



  reply	other threads:[~2019-06-11 19:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 13:36 [RFC v2 0/5] cgroup-aware unbound workqueues Daniel Jordan
2019-06-05 13:36 ` [RFC v2 1/5] cgroup: add cgroup v2 interfaces to migrate kernel threads Daniel Jordan
2019-06-05 13:36 ` [RFC v2 2/5] workqueue, cgroup: add cgroup-aware workqueues Daniel Jordan
2019-06-05 13:36 ` [RFC v2 3/5] workqueue, memcontrol: make memcg throttle workqueue workers Daniel Jordan
2019-06-05 13:36 ` [RFC v2 4/5] workqueue, cgroup: add test module Daniel Jordan
2019-06-05 13:36 ` [RFC v2 5/5] ktask, cgroup: attach helper threads to the master thread's cgroup Daniel Jordan
2019-06-05 13:53 ` [RFC v2 0/5] cgroup-aware unbound workqueues Tejun Heo
2019-06-05 15:32   ` Daniel Jordan
2019-06-11 19:55     ` Tejun Heo [this message]
2019-06-12 22:29       ` Daniel Jordan
2019-06-06  6:15   ` Mike Rapoport
2019-06-11 19:52     ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).