All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Joel Schopp <jschopp@austin.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Anton Blanchard <anton@au1.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: questions on calc_delta_mine() in sched.c
Date: Fri, 02 May 2008 20:55:39 +0200	[thread overview]
Message-ID: <1209754539.6929.7.camel@lappy> (raw)
In-Reply-To: <481B6175.6070207@austin.ibm.com>

On Fri, 2008-05-02 at 13:46 -0500, Joel Schopp wrote:
> > This one builds and... boots
> 
> I'll try to test in on my end.
> 
> > +	struct load_weight lw_cache[4];
> > +	int lw_cache_idx;
> > +
> >  	struct cfs_rq cfs;
> >  	struct rt_rq rt;
> >  
> > @@ -1438,8 +1441,24 @@ calc_delta_mine(unsigned long delta_exec
> >  {
> >  	u64 tmp;
> >  
> > -	if (unlikely(!lw->inv_weight))
> > -		lw->inv_weight = (WMULT_CONST-lw->weight/2) / (lw->weight+1);
> > +	if (!lw->inv_weight) {
> 
> Yep, got to get rid of unlikely.
> 
> > +		struct rq *rq = cpu_rq(smp_processor_id());
> > +		unsigned long weight = lw->weight;
> > +		int i;
> > +
> > +		for (i = 0; i < ARRAY_SIZE(rq->lw_cache); i++) {
> > +			if (rq->lw_cache[i].weight == weight)
> > +				lw->inv_weight = rq->lw_cache[i].inv_weight;
> > +			goto got_inv;
> > +		}
> > +		if (unlikely(!weight))
> > +			weight++;
> > +		lw->inv_weight = 1 + (WMULT_CONST - weight/2) / weight;
> 
> I bet just dividing by weight + 1 unconditionally would be cheaper than 
> doing the test and shouldn't skew results too badly.

Yeah... probably - getting rid of that one case where it can happen is
on my todo list somewhere.

> > +		rq->lw_cache[rq->lw_cache_idx] = *lw;
> > +		rq->lw_cache_idx++;
> > +		rq->lw_cache_idx %= ARRAY_SIZE(rq->lw_cache);
> > +	}
> > + got_inv:
> 
> Doctor, I think the cure is worse than the disease.   I'd expect that even 
> if all these extra loads hit cache they should together be more expensive 
> than the divide they save.   Not that I have any better solutions myself.

Probably, but since you seemed in benchmarking mood I thought you might
as well give it a go ;-)

> I think a patch to get rid of unlikely and to change these two div64_64 to 
> 0s should be pushed up.  Not sure what we do about the divide.

Ok, I'll stick such a patch in to to-mingo queue ;-)


  reply	other threads:[~2008-05-02 18:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-01 20:45 questions on calc_delta_mine() in sched.c Joel Schopp
2008-05-02 12:14 ` Peter Zijlstra
2008-05-02 12:30   ` Peter Zijlstra
2008-05-02 13:10     ` Peter Zijlstra
2008-05-02 18:46       ` Joel Schopp
2008-05-02 18:55         ` Peter Zijlstra [this message]
2008-05-02 20:30   ` Joel Schopp

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=1209754539.6929.7.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=anton@au1.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=jschopp@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.