From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: bharata@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Gautham R Shenoy <ego@in.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Ingo Molnar <mingo@elte.hu>, Pavel Emelyanov <xemul@openvz.org>,
Herbert Poetzl <herbert@13thfloor.at>,
Avi Kivity <avi@redhat.com>, Chris Friesen <cfriesen@nortel.com>,
Paul Menage <menage@google.com>,
Mike Waychison <mikew@google.com>
Subject: Re: [RFC v2 PATCH 4/8] sched: Enforce hard limits by throttling
Date: Tue, 13 Oct 2009 16:27:00 +0200 [thread overview]
Message-ID: <1255444020.8392.362.camel@twins> (raw)
In-Reply-To: <20090930125252.GE19951@in.ibm.com>
On Wed, 2009-09-30 at 18:22 +0530, Bharata B Rao wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 0f1ea4a..77ace43 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1024,7 +1024,7 @@ struct sched_domain;
> struct sched_class {
> const struct sched_class *next;
>
> - void (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
> + int (*enqueue_task) (struct rq *rq, struct task_struct *p, int wakeup);
> void (*dequeue_task) (struct rq *rq, struct task_struct *p, int sleep);
> void (*yield_task) (struct rq *rq);
>
I really hate this, it uglfies all the enqueue code in a horrid way
(which is most of this patch).
Why can't we simply enqueue the task on a throttled group just like rt?
> @@ -3414,6 +3443,18 @@ int can_migrate_task(struct task_struct *p, struct rq *rq, int this_cpu,
> }
>
> /*
> + * Don't migrate the task if it belongs to a
> + * - throttled group on its current cpu
> + * - throttled group on this_cpu
> + * - group whose hierarchy is throttled on this_cpu
> + */
> + if (cfs_rq_throttled(cfs_rq_of(&p->se)) ||
> + task_group_throttled(task_group(p), this_cpu)) {
> + schedstat_inc(p, se.nr_failed_migrations_throttled);
> + return 0;
> + }
> +
> + /*
> * Aggressive migration if:
> * 1) task is cache cold, or
> * 2) too many balance attempts have failed.
Simply don't iterate throttled groups?
next prev parent reply other threads:[~2009-10-13 14:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-30 12:49 [RFC v2 PATCH 0/8] CFS Hard limits - v2 Bharata B Rao
2009-09-30 12:50 ` [RFC v2 PATCH 1/8] sched: Rename sched_rt_period_mask() and use it in CFS also Bharata B Rao
2009-09-30 12:51 ` [RFC v2 PATCH 2/8] sched: Maintain aggregated tasks count in cfs_rq at each hierarchy level Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra
2009-10-14 3:42 ` Bharata B Rao
2009-09-30 12:52 ` [RFC v2 PATCH 3/8] sched: Bandwidth initialization for fair task groups Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra
2009-10-14 3:49 ` Bharata B Rao
2009-09-30 12:52 ` [RFC v2 PATCH 4/8] sched: Enforce hard limits by throttling Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra [this message]
2009-10-14 3:41 ` Bharata B Rao
2009-10-14 9:17 ` Peter Zijlstra
2009-10-14 11:50 ` Bharata B Rao
2009-10-14 13:18 ` Herbert Poetzl
2009-10-15 3:30 ` Bharata B Rao
2009-09-30 12:53 ` [RFC v2 PATCH 5/8] sched: Unthrottle the throttled tasks Bharata B Rao
2009-09-30 12:54 ` [RFC v2 PATCH 6/8] sched: Add throttle time statistics to /proc/sched_debug Bharata B Rao
2009-09-30 12:55 ` [RFC v2 PATCH 7/8] sched: Rebalance cfs runtimes Bharata B Rao
2009-09-30 12:55 ` [RFC v2 PATCH 8/8] sched: Hard limits documentation Bharata B Rao
2009-09-30 13:36 ` [RFC v2 PATCH 0/8] CFS Hard limits - v2 Pavel Emelyanov
2009-09-30 14:25 ` Bharata B Rao
2009-09-30 14:39 ` Srivatsa Vaddagiri
2009-09-30 15:09 ` Pavel Emelyanov
2009-10-13 11:39 ` Pavel Emelyanov
2009-10-13 12:03 ` Herbert Poetzl
2009-10-13 12:19 ` Pavel Emelyanov
2009-10-13 12:30 ` Dhaval Giani
2009-10-13 12:45 ` Pavel Emelyanov
2009-10-13 12:56 ` Dhaval Giani
2009-10-13 12:57 ` Bharata B Rao
2009-10-13 13:01 ` Pavel Emelyanov
2009-10-13 14:56 ` Valdis.Kletnieks
2009-10-13 22:02 ` Herbert Poetzl
2009-10-13 14:49 ` Valdis.Kletnieks
2009-09-30 14:38 ` Balbir Singh
2009-09-30 15:10 ` Pavel Emelyanov
2009-09-30 15:30 ` Balbir Singh
2009-09-30 22:30 ` Herbert Poetzl
2009-10-01 5:12 ` Bharata B Rao
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=1255444020.8392.362.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=avi@redhat.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=cfriesen@nortel.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=ego@in.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mikew@google.com \
--cc=mingo@elte.hu \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=xemul@openvz.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.