public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling•org>
To: balbir@linux•vnet.ibm.com
Cc: linuxppc-dev@ozlabs•org, paulus@samba•org
Subject: Re: [PATCH] fix scaled time accounting possible divide by zero
Date: Tue, 20 Nov 2007 15:36:49 +1100	[thread overview]
Message-ID: <19947.1195533409@neuling.org> (raw)
In-Reply-To: <47425F8F.3060208@linux.vnet.ibm.com>

In message <47425F8F.3060208@linux•vnet.ibm.com> you wrote:
> Michael Neuling wrote:
> > This fixes a problem noticed by Balbir Singh
> > 
> > Signed-off-by: Michael Neuling <mikey@neuling•org>
> > ---
> > Paulus: can we send this up for 2.6.24?
> > 
> >  arch/powerpc/kernel/time.c |    5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > Index: linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/time.c
> > +++ linux-2.6-ozlabs/arch/powerpc/kernel/time.c
> > @@ -244,8 +244,9 @@ void account_system_vtime(struct task_st
> >  		/* deltascaled includes both user and system time.
> >  		 * Hence scale it based on the purr ratio to estimate
> >  		 * the system time */
> > -		deltascaled = deltascaled * get_paca()->system_time /
> > -		(get_paca()->system_time + get_paca()->user_time);
> > +		if (get_paca()->user_time)
> > +			deltascaled = deltascaled * get_paca()->system_time /
> > +			(get_paca()->system_time + get_paca()->user_time);
> 
> Hi, Michael,
> 
> I'd be doubly careful with scaled multiplication approach, we tried this
> for CFS (please see task_utime() and task_stime() and the fixes that
> went around it). We ran into problems were due to multiplication
> rounding errors, we would see stime and utime go back after a period
> of time.
> 
> Please see http://kerneltrap.org/mailarchive/linux-kernel/2007/10/16/344377
> 
> Our problems were made severe by the fact that sum_exec_runtime and
> stime/utime accounting occured differently. stime/utime were sampled
> at jiffy boundaries and hence could we incorrect. I think we need
> to use rounding to ensure that ac_scaled*time never goes back
> due to rounding errors.

I've not changed the math here much, just the case of user_time being
zero.

Is this related to this patch specifically, or something that's been
wrong with these patches for a while?

Mikey

  reply	other threads:[~2007-11-20  4:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20  3:25 [PATCH] fix scaled time accounting possible divide by zero Michael Neuling
2007-11-20  4:16 ` Balbir Singh
2007-11-20  4:36   ` Michael Neuling [this message]
2007-11-20  4:18 ` Michael Neuling

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=19947.1195533409@neuling.org \
    --to=mikey@neuling$(echo .)org \
    --cc=balbir@linux$(echo .)vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    --cc=paulus@samba$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox