All of lore.kernel.org
 help / color / mirror / Atom feed
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 3/8] sched: Bandwidth initialization for fair task groups
Date: Tue, 13 Oct 2009 16:27:01 +0200	[thread overview]
Message-ID: <1255444021.8392.363.camel@twins> (raw)
In-Reply-To: <20090930125204.GD19951@in.ibm.com>

On Wed, 2009-09-30 at 18:22 +0530, Bharata B Rao wrote:

> diff --git a/kernel/sched.c b/kernel/sched.c
> index c283d0f..0147f6f 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -262,6 +262,15 @@ static DEFINE_MUTEX(sched_domains_mutex);
>  
>  #include <linux/cgroup.h>
>  
> +#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_CFS_HARD_LIMITS)
> +struct cfs_bandwidth {
> +	spinlock_t		cfs_runtime_lock;
> +	ktime_t			cfs_period;
> +	u64			cfs_runtime;
> +	struct hrtimer		cfs_period_timer;
> +};
> +#endif

too much cfs here..

>  struct cfs_rq;
>  
>  static LIST_HEAD(task_groups);
> @@ -282,6 +291,11 @@ struct task_group {
>  	/* runqueue "owned" by this group on each cpu */
>  	struct cfs_rq **cfs_rq;
>  	unsigned long shares;
> +#ifdef CONFIG_CFS_HARD_LIMITS
> +	struct cfs_bandwidth cfs_bandwidth;
> +	/* If set, throttle when the group exceeds its bandwidth */
> +	int hard_limit_enabled;
> +#endif

What's wrong with doing something like cfs_bandwidth.cfs_runtime ==
RUNTIME_INF ?

>  #endif
>  
>  #ifdef CONFIG_RT_GROUP_SCHED
> @@ -477,6 +491,16 @@ struct cfs_rq {
>  	unsigned long rq_weight;
>  #endif
>  #endif
> +#ifdef CONFIG_CFS_HARD_LIMITS
> +	/* set when the group is throttled  on this cpu */
> +	int cfs_throttled;
> +
> +	/* runtime currently consumed by the group on this rq */
> +	u64 cfs_time;
> +
> +	/* runtime available to the group on this rq */
> +	u64 cfs_runtime;
> +#endif

too much cfs_ again.

>  	/*
>  	 * Number of tasks at this heirarchy.
>  	 */
> @@ -665,6 +689,11 @@ struct rq {
>  	/* BKL stats */
>  	unsigned int bkl_count;
>  #endif
> +	/*
> +	 * Protects the cfs runtime related fields of all cfs_rqs under
> +	 * this rq
> +	 */
> +	spinlock_t runtime_lock;
>  };
>  
>  static DEFINE_PER_CPU_SHARED_ALIGNED(struct rq, runqueues);


> +static inline void rq_runtime_lock(struct rq *rq)
> +{
> +	spin_lock(&rq->runtime_lock);
> +}
> +
> +static inline void rq_runtime_unlock(struct rq *rq)
> +{
> +	spin_unlock(&rq->runtime_lock);
> +}

needless obfuscation.

> CONFIG_RT_GROUP_SCHED
> @@ -10317,6 +10617,23 @@ static struct cftype cpu_files[] = {
>  		.read_u64 = cpu_shares_read_u64,
>  		.write_u64 = cpu_shares_write_u64,
>  	},
> +#ifdef CONFIG_CFS_HARD_LIMITS
> +	{
> +		.name = "cfs_runtime_us",
> +		.read_s64 = cpu_cfs_runtime_read_s64,
> +		.write_s64 = cpu_cfs_runtime_write_s64,
> +	},
> +	{
> +		.name = "cfs_period_us",
> +		.read_u64 = cpu_cfs_period_read_u64,
> +		.write_u64 = cpu_cfs_period_write_u64,
> +	},
> +	{
> +		.name = "cfs_hard_limit",
> +		.read_u64 = cpu_cfs_hard_limit_read_u64,
> +		.write_u64 = cpu_cfs_hard_limit_write_u64,
> +	},
> +#endif /* CONFIG_CFS_HARD_LIMITS */
>  #endif
>  #ifdef CONFIG_RT_GROUP_SCHED
>  	{

I guess that cfs_hard_limit thing is superfluous as well.


  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 [this message]
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
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=1255444021.8392.363.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.