archive mirror
 help / color / mirror / Atom feed
From: Josh Don <>
To: Tejun Heo <>
Cc: Ingo Molnar <>,
	Peter Zijlstra <>,
	Juri Lelli <>,
	Vincent Guittot <>,
	Dietmar Eggemann <>,
	Steven Rostedt <>,
	Ben Segall <>, Mel Gorman <>,
	Daniel Bristot de Oliveira <>,
	Paul Turner <>,
	David Rientjes <>,
	Oleg Rombakh <>,
	Viresh Kumar <>,
	Steve Sistare <>,
	linux-kernel <>,
	Rik van Riel <>
Subject: Re: [PATCH] sched: cgroup SCHED_IDLE support
Date: Mon, 28 Jun 2021 21:57:42 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Jun 26, 2021 at 2:57 AM Tejun Heo <> wrote:
> Would you care to share some concrete use cases?
> Thank you.
> --
> tejun

Sure thing, there are two use cases we've found compelling:

1. On a machine, different users are given their own top-level cgroup
(configured with an appropriate number of shares). Each user is free
to spawn any threads and create any additional cgroups within their
top-level group.
Some users would like to run high priority, latency-sensitive work
(for example, responding to an RPC) as well as some batch tasks (ie.
background work such as data manipulation, transcoding, etc.) within
their cgroup. The batch tasks should interfere minimally with the high
priority work. However, it is still desired that this batch work be
considered the same as the high priority work vs the jobs of some
other user on the machine.

To achieve this, the user sets up two sub-cgroups, one of which is
marked as idle. The idle cgroup will always be preempted on wakeup of
a task in the other sub-cgroup (but not a wakeup of another user's
task). This is not possible with the per-task SCHED_IDLE setting.
Cgroup shares/weight alone is also not as strong as SCHED_IDLE.

2. We can create a top-level idle cgroup in which we place users who
want to run some best-effort work (ie. some long running
computations). Since it is the top-level cgroup that is marked idle,
any other task on the machine will always preempt something running
within the top-level idle cgroup. We can also easily maintain the
relative weights between different users within the idle group.

This top-level idle group allows for soaking otherwise unused cycles,
and offers cheap machine quota for users who have latency-tolerant

  reply	other threads:[~2021-06-29  4:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 23:11 [PATCH] sched: cgroup SCHED_IDLE support Josh Don
2021-06-10 12:53 ` Dietmar Eggemann
2021-06-10 19:14   ` Josh Don
2021-06-11 16:43     ` Dietmar Eggemann
2021-06-11 23:34       ` Josh Don
2021-06-15 10:06         ` Dietmar Eggemann
2021-06-15 23:30           ` Josh Don
2021-06-25  9:24           ` Peter Zijlstra
2021-06-16 15:42 ` Tejun Heo
2021-06-17  1:01   ` Josh Don
2021-06-26  9:57     ` Tejun Heo
2021-06-29  4:57       ` Josh Don [this message]
2021-06-25  8:08   ` Peter Zijlstra
2021-06-26 10:06     ` Tejun Heo
2021-06-26 11:42     ` Rik van Riel
2021-06-25  8:14 ` Peter Zijlstra
2021-06-26  0:18   ` Josh Don
2021-06-25  8:20 ` Peter Zijlstra
2021-06-26  0:35   ` Josh Don

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).