All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	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 v5 PATCH 1/8] sched: Rename struct rt_bandwidth to sched_bandwidth
Date: Fri, 29 Jan 2010 19:37:31 +0530	[thread overview]
Message-ID: <20100129140731.GA3532@in.ibm.com> (raw)
In-Reply-To: <20100129085949.GD25191@balbir.in.ibm.com>

On Fri, Jan 29, 2010 at 02:29:49PM +0530, Balbir Singh wrote:
> * Bharata B Rao <bharata@linux.vnet.ibm.com> [2010-01-05 13:28:24]:
> 
> > sched: Rename struct rt_bandwidth to sched_bandwidth
> > 
> > From: Dhaval Giani <dhaval@linux.vnet.ibm.com>
> > 
> > Rename struct rt_bandwidth to sched_bandwidth and rename some of the
> > routines to generic names (s/rt_/sched_) so that they can be used
> > by CFS hard limits code in the subsequent patches.
> > 
> > No functionality change by this patch.
> > 
> > Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> 
> Looks good, some nit picks below
> 
> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>

Thanks Balbir.

> 
> 
> > ---
> >  kernel/sched.c    |  127 ++++++++++++++++++++++++++---------------------------
> >  kernel/sched_rt.c |   46 ++++++++++---------
> >  2 files changed, 86 insertions(+), 87 deletions(-)
> > 
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index c535cc4..21cf0d5 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -139,50 +139,50 @@ struct rt_prio_array {
> >  	struct list_head queue[MAX_RT_PRIO];
> >  };
> > 
> > -struct rt_bandwidth {
> > +struct sched_bandwidth {
> >  	/* nests inside the rq lock: */
> > -	raw_spinlock_t		rt_runtime_lock;
> > -	ktime_t			rt_period;
> > -	u64			rt_runtime;
> > -	struct hrtimer		rt_period_timer;
> > +	raw_spinlock_t		runtime_lock;
> > +	ktime_t			period;
> > +	u64			runtime;
> > +	struct hrtimer		period_timer;
> >  };
> > 
> > -static struct rt_bandwidth def_rt_bandwidth;
> > +static struct sched_bandwidth def_rt_bandwidth;
> > 
> > -static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun);
> > +static int do_sched_rt_period_timer(struct sched_bandwidth *sched_b, int overrun);
> > 
> >  static enum hrtimer_restart sched_rt_period_timer(struct hrtimer *timer)
> >  {
> > -	struct rt_bandwidth *rt_b =
> > -		container_of(timer, struct rt_bandwidth, rt_period_timer);
> > +	struct sched_bandwidth *sched_b =
> > +		container_of(timer, struct sched_bandwidth, period_timer);
> >  	ktime_t now;
> >  	int overrun;
> >  	int idle = 0;
> > 
> >  	for (;;) {
> >  		now = hrtimer_cb_get_time(timer);
> > -		overrun = hrtimer_forward(timer, now, rt_b->rt_period);
> > +		overrun = hrtimer_forward(timer, now, sched_b->period);
> > 
> >  		if (!overrun)
> >  			break;
> > 
> > -		idle = do_sched_rt_period_timer(rt_b, overrun);
> > +		idle = do_sched_rt_period_timer(sched_b, overrun);
> >  	}
> > 
> >  	return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
> >  }
> > 
> > -static
> > -void init_rt_bandwidth(struct rt_bandwidth *rt_b, u64 period, u64 runtime)
> > +static void init_sched_bandwidth(struct sched_bandwidth *sched_b, u64 period,
> > +	u64 runtime, enum hrtimer_restart (*period_timer)(struct hrtimer *))
> >  {
> > -	rt_b->rt_period = ns_to_ktime(period);
> > -	rt_b->rt_runtime = runtime;
> > +	sched_b->period = ns_to_ktime(period);
> > +	sched_b->runtime = runtime;
> > 
> > -	raw_spin_lock_init(&rt_b->rt_runtime_lock);
> > +	raw_spin_lock_init(&sched_b->runtime_lock);
> > 
> > -	hrtimer_init(&rt_b->rt_period_timer,
> > +	hrtimer_init(&sched_b->period_timer,
> >  			CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> > -	rt_b->rt_period_timer.function = sched_rt_period_timer;
> > +	sched_b->period_timer.function = *period_timer;
> 
> Hmm.. may be I forgetting the "C" language, but why do you dereference
> the pointer before assignment? You should be able to directly assign a
> function address to the function pointer. Did you see a warning?

This is a carry over from old patches. I will fix this
in the next iteration.

> 
> >  }
> > 
> >  static inline int rt_bandwidth_enabled(void)
> > @@ -190,42 +190,40 @@ static inline int rt_bandwidth_enabled(void)
> >  	return sysctl_sched_rt_runtime >= 0;
> >  }
> > 
> > -static void start_rt_bandwidth(struct rt_bandwidth *rt_b)
> > +static void start_sched_bandwidth(struct sched_bandwidth *sched_b)
> >  {
> >  	ktime_t now;
> > 
> > -	if (!rt_bandwidth_enabled() || rt_b->rt_runtime == RUNTIME_INF)
> > +	if (!rt_bandwidth_enabled() || sched_b->runtime == RUNTIME_INF)
> >  		return;
> > 
> > -	if (hrtimer_active(&rt_b->rt_period_timer))
> > +	if (hrtimer_active(&sched_b->period_timer))
> >  		return;
> > 
> > -	raw_spin_lock(&rt_b->rt_runtime_lock);
> > +	raw_spin_lock(&sched_b->runtime_lock);
> 
> I don't quite understand why this is a raw_spin_lock

- When upgrading from v4 (2.6.32-rc6) to v5 (2.6.33-rc2), I needed
  to change most of the spin_locks in hard limits code in sched.c
  since they had become raw_spin_lock_t.
- If your question is why couldn't we use spin_lock_t (sleepable types),
  this routine is called from RT and CFS with rq->lock (raw type) held.
  So I guess it is not possible to use sleepable version here.

Thanks for your reivew. Would appreciate review of other patches also :)

Regards,
Bharata.

  reply	other threads:[~2010-01-29 14:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-05  7:57 [RFC v5 PATCH 0/8] CFS Hard limits - v5 Bharata B Rao
2010-01-05  7:58 ` [RFC v5 PATCH 1/8] sched: Rename struct rt_bandwidth to sched_bandwidth Bharata B Rao
2010-01-29  8:59   ` Balbir Singh
2010-01-29 14:07     ` Bharata B Rao [this message]
2010-01-05  7:59 ` [RFC v5 PATCH 2/8] sched: Make rt bandwidth timer and runtime related code generic Bharata B Rao
2010-01-05  8:00 ` [RFC v5 PATCH 3/8] sched: Bandwidth initialization for fair task groups Bharata B Rao
2010-01-05  8:01 ` [RFC v5 PATCH 4/8] sched: Enforce hard limits by throttling Bharata B Rao
2010-01-05  8:01 ` [RFC v5 PATCH 5/8] sched: Unthrottle the throttled tasks Bharata B Rao
2010-01-05  8:02 ` [RFC v5 PATCH 6/8] sched: Add throttle time statistics to /proc/sched_debug Bharata B Rao
2010-01-05  8:03 ` [RFC v5 PATCH 7/8] sched: CFS runtime borrowing Bharata B Rao
2010-01-06  5:02   ` Bharata B Rao
2010-01-05  8:04 ` [RFC v5 PATCH 8/8] sched: Hard limits documentation Bharata B Rao
2010-01-05  8:06 ` [RFC v5 PATCH 0/8] CFS Hard limits - v5 Bharata B Rao
2010-01-08 20:45 ` Paul Turner
2010-01-29  3:49   ` Bharata B Rao
2010-01-29  4:26     ` Paul Turner
2010-02-01  8:21       ` Bharata B Rao
2010-02-01 11:04         ` Paul Turner
2010-02-01 18:25           ` Paul Turner
2010-02-02  4:14             ` Bharata B Rao
2010-02-02  7:13               ` Paul Turner
2010-02-02  7:57                 ` 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=20100129140731.GA3532@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=avi@redhat.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=cfriesen@nortel.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=herbert@13thfloor.at \
    --cc=kamalesh@linux.vnet.ibm.com \
    --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.