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>
Subject: Re: questions on calc_delta_mine() in sched.c
Date: Fri, 02 May 2008 14:14:01 +0200	[thread overview]
Message-ID: <1209730442.6508.3.camel@lappy> (raw)
In-Reply-To: <481A2BF6.2070406@austin.ibm.com>

On Thu, 2008-05-01 at 15:45 -0500, Joel Schopp wrote:
> Ingo,
> 
> I have a few questions regarding  this code in kernel/sched.c
> 
> static unsigned long
> calc_delta_mine(unsigned long delta_exec, unsigned long weight,
>          struct load_weight *lw)
> {
>      u64 tmp;
> 
>      if (unlikely(!lw->inv_weight))
>          lw->inv_weight = (WMULT_CONST-lw->weight/2) / (lw->weight+1);
> 
> 
> Q1) This code is hit often in scenarios I run, is this really unlikely for 
> others?

I think it became a lot more likely recently, perhaps removing that
unlikely is not such a bad idea.

> Q2) The rest of the code in sched.c seems to make inv_weight == 
> WMULT_CONST/weight and I was wondering if you could explain why this 
> instance is different.

because the rest of the code is wrong, there are only 2 other sites, and
I have a patch that removes those div64_64() with =0;

The idea is to use rounding division: (x + y/2) / y
but we can't because 'x' is touching the limits of our modulo space,
hence we do: (x - y/2) / y
which comes in 1 short, that fixup has been lost along the way.

> Q3) That division is pretty expensive, could we sacrifice some accuracy and 
> do a precompute table?  Do you have another idea how we could get rid of 
> the divide?

Is a full memory miss not more expensive on most modern machines?

And, no sadly I have no ideas on how to get rid of it ;-/


  reply	other threads:[~2008-05-02 12:14 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 [this message]
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
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=1209730442.6508.3.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --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.