All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: Tim Schmielau <tim@physik3.uni-rostock.de>
Cc: vda <vda@port.imtp.ilyichevsk.odessa.ua>,
	"Richard B. Johnson" <root@chaos.analogic.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Patch] Re: Nasty suprise with uptime
Date: Wed, 31 Oct 2001 14:07:43 -0700	[thread overview]
Message-ID: <20011031140743.P16554@lynx.no> (raw)
In-Reply-To: <01103121070200.01262@nemo> <Pine.LNX.4.30.0110312138040.30038-100000@gans.physik3.uni-rostock.de>
In-Reply-To: <Pine.LNX.4.30.0110312138040.30038-100000@gans.physik3.uni-rostock.de>; from tim@physik3.uni-rostock.de on Wed, Oct 31, 2001 at 09:47:52PM +0100

On Oct 31, 2001  21:47 +0100, Tim Schmielau wrote:
> OK, I introduced get_jiffies64, corrected my 64 bit mistake and
> subtract INITIAL_JIFFIES to obtain uptime, while leaving it at at pre-wrap
> value for error-chasing.
> Still this patch introduces jiffies_high on 64 bit platforms which will be
> useless until the year 571234830.

It probably won't be accepted until the whole thing disappears for 64-bit
systems.

> btw.: can someone please explain to me why do_timer uses
> 	(*(unsigned long *)&jiffies)++;
> instead of just doing jiffies++ ?

Can't say for sure, but it may be a compiler issue, maybe historical.


>  	 */
>  #if HZ!=100
>  	len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
> -		uptime / HZ,
> -		(((uptime % HZ) * 100) / HZ) % 100,
> +		(unsigned long) uptime,
> +		((remainder * 100) / HZ) % 100,
>  		idle / HZ,
>  		(((idle % HZ) * 100) / HZ) % 100);

Given that uptime is now 64-bits, do we need this mathematical hoop jumping?
Also, won't the remainder already be modulus HZ in this case?

>  void do_timer(struct pt_regs *regs)
>  {
> -	(*(unsigned long *)&jiffies)++;
> +	/* we assume that two calls to do_timer can never overlap
> +	 * since they are one jiffie apart in time */
> +	if (jiffies != (unsigned long)(-1)) {
> +		jiffies++;
> +	} else {
> +		/* We still need to care about the race with readers of
> +		 * jiffies_hi. Readers have to discard the values if
> +		 * jiffies_hi != jiffies_hi_shadow when read with
> +		 * proper barriers in between. */
> +		jiffies_hi++;
> +		barrier();
> +		jiffies++;
> +		barrier();
> +		jiffies_hi_shadow = jiffies_hi;
> +		barrier();
> +	}

I think this is the part of the patch that people object to.  See my
other posting of how to handle 64-bit jiffies with only an impact to
users of the 64-bit value.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


  reply	other threads:[~2001-10-31 21:09 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <01103121070200.01262@nemo>
2001-10-31 19:26 ` [Patch] Re: Nasty suprise with uptime Tim Schmielau
2001-10-31 19:52   ` Richard B. Johnson
2001-10-31 20:00     ` J Sloan
2001-10-31 20:20     ` Charles Cazabon
2001-10-31 20:33       ` Kurt Roeckx
2001-10-31 20:47 ` Tim Schmielau
2001-10-31 21:07   ` Andreas Dilger [this message]
2001-10-31 21:11   ` Richard B. Johnson
2001-11-01 16:09   ` vda
2001-11-01  9:02 Petr Vandrovec
  -- strict thread matches above, loose matches on Subject: below --
2001-10-31 22:11 Petr Vandrovec
2001-10-31 21:45 ` Andreas Dilger
2001-10-31 22:58 ` Tim Schmielau
2001-10-31 23:56   ` Andreas Dilger
2001-11-01  0:23     ` Tim Schmielau
2001-11-01  0:52       ` Tim Schmielau
2001-11-01 11:21         ` george anzinger
2001-11-01 11:40           ` Tim Schmielau
2001-11-02  0:28             ` Tim Schmielau
2001-11-02  1:23               ` Andreas Dilger
2001-11-02  9:10                 ` Miquel van Smoorenburg
2001-11-02 17:18                 ` Tim Schmielau
2001-11-02 18:48                   ` Andreas Dilger
2001-11-01 16:35         ` vda
2001-11-01 15:34           ` Richard B. Johnson
2001-11-01 17:02             ` Benjamin LaHaise
2001-11-01 18:03               ` Richard B. Johnson
2001-11-01 18:34                 ` Benjamin LaHaise
2001-11-02 14:46                   ` vda
2001-11-01 17:29             ` george anzinger
2001-10-31 11:35 Tim Schmielau
2001-10-31 15:39 ` vda
2001-10-31 14:31   ` Richard B. Johnson
2001-10-31 18:16     ` Tim Schmielau
2001-10-31 18:35       ` Tim Schmielau
2001-10-31 18:59         ` Andreas Dilger
2001-10-31 18:40       ` Andreas Dilger
2001-10-31 18:58         ` Gerhard Mack
2001-10-31 19:14           ` Richard B. Johnson
2001-10-31 20:11             ` Gerhard Mack
2001-10-31 20:39               ` Richard B. Johnson
2001-10-31 20:52               ` Andreas Dilger
2001-10-31 21:05                 ` Tim Schmielau
2001-10-31 21:39                   ` Andreas Dilger
2001-10-31 21:17                 ` Richard B. Johnson
2001-11-01  7:45                   ` Ville Herva
2001-10-31 19:06       ` george anzinger
2001-10-31 22:54       ` george anzinger
2001-11-04 18:31         ` Ton Hospel

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=20011031140743.P16554@lynx.no \
    --to=adilger@turbolabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    --cc=tim@physik3.uni-rostock.de \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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.