Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: James.Bottomley@SteelEye.com, soete.joel@scarlet.be,
	parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] [PATCH] timer_interrupt and gettimeoffset.
Date: Sun, 3 Sep 2006 18:09:37 -0600	[thread overview]
Message-ID: <20060904000937.GA6963@colo.lackof.org> (raw)
In-Reply-To: <200609031959.k83JxYon019649@hiauly1.hia.nrc.ca>

On Sun, Sep 03, 2006 at 03:59:34PM -0400, John David Anglin wrote:
> > Is it ok if I only add the irqsave/restore to my current patch?
> > I also like the "avoid div/mul ops" test too.
> 
> I agree on that.  They are very expensive, especially in 64-bit code.
> 
> I'm playing with the patch below.  The main thing I tried to do is
> reduce the amount of code in the irqsave/restore.

I've not applied the irqsave/restore since I don't think it does anything.
do_cpu_irq_mask() doesn't allow nested external interrupts.

> GCC didn't do a great job of optimizing the code.  I think we would
> get better code if clocktick and halftick were copied to temps before
> the irqsave.

hrm...I would expect the same result from __read_mostly but can understand
why that's not as useful as I hoped.

Can we tell GCC that clocktick doesn't change during execution of this code?
ie despite being a global, it's a "constant" and doesn't need to be
reloaded on each loop iteration?


> I was also concerned about nticks not being unsigned long.

I agree. I'm leaning very strongly in favor of the unsigned version
of the code. Even though I think Carlos demonstrated the signed
math is correct. So unless someone objects to the unsigned version
I posted earlier soon (assuming I address all bug fixes), I'd like
to commit that in the next couple of days.

thanks,
grant

> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
> 
> Index: time.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/arch/parisc/kernel/time.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 time.c
> --- time.c	24 Jun 2006 16:05:18 -0000	1.16
> +++ time.c	3 Sep 2006 19:42:24 -0000
> @@ -47,29 +47,34 @@ irqreturn_t timer_interrupt(int irq, voi
>  {
>  	long now;
>  	long next_tick;
> -	int nticks;
> +	unsigned long nticks = 0;
>  	int cpu = smp_processor_id();
> +	long flags;
>  
>  	profile_tick(CPU_PROFILING, regs);
>  
> -	now = mfctl(16);
> -	/* initialize next_tick to time at last clocktick */
> +	/* Initialize next_tick to time at last clocktick */
>  	next_tick = cpu_data[cpu].it_value;
>  
> -	/* since time passes between the interrupt and the mfctl()
> -	 * above, it is never true that last_tick + clocktick == now.  If we
> -	 * never miss a clocktick, we could set next_tick = last_tick + clocktick
> -	 * but maybe we'll miss ticks, hence the loop.
> +	/* Since time passes between the interrupt and the mfctl(),
> +	 * it is never true that last_tick + clocktick == now.
> +	 * If we never miss a clocktick, we could set
> +	 * next_tick = last_tick + clocktick, * but maybe we'll miss
> +	 * ticks, hence the loop.
>  	 *
>  	 * Variables are *signed*.
>  	 */
>  
> -	nticks = 0;
> +	/* Don't want to be interrupted while calculating
> +	 * the time for the next tick.  */
> +	local_irq_save(flags);
> +	now = mfctl(16);
>  	while((next_tick - now) < halftick) {
>  		next_tick += clocktick;
>  		nticks++;
>  	}
>  	mtctl(next_tick, 16);
> +	local_irq_restore(flags);
>  	cpu_data[cpu].it_value = next_tick;
>  
>  	while (nticks--) {
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2006-09-04  0:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 16:38 Re:[parisc-linux] [PATCH] timer_interrupt and gettimeoffset Joel Soete
2006-08-30 16:52 ` [parisc-linux] " Grant Grundler
2006-08-30 20:23   ` Carlos O'Donell
2006-09-02 15:52     ` James Bottomley
2006-09-03 15:00       ` Carlos O'Donell
2006-09-03 15:17         ` James Bottomley
2006-09-03 16:14         ` James Bottomley
2006-09-03 19:31           ` Grant Grundler
2006-09-04 15:51             ` James Bottomley
2006-09-04 16:57               ` John David Anglin
2006-09-04 17:23                 ` James Bottomley
2006-09-04 19:12                   ` John David Anglin
2006-09-04 21:21                 ` Grant Grundler
2006-09-04 22:47                   ` James Bottomley
2006-09-04 23:52                     ` John David Anglin
2006-09-05  5:12                       ` Grant Grundler
2006-09-05 15:53                         ` James Bottomley
2006-09-05 22:49                           ` Grant Grundler
2006-09-05 22:59                             ` James Bottomley
2006-09-05 23:41                             ` John David Anglin
2006-09-06  0:24                         ` John David Anglin
2006-09-03 19:38       ` Grant Grundler
2006-09-03 19:59         ` John David Anglin
2006-09-04  0:09           ` Grant Grundler [this message]
2006-09-04  0:58             ` John David Anglin
2006-09-04  3:51             ` John David Anglin
2006-09-04 15:49         ` James Bottomley
     [not found] <44FDE867.3090204@scarlet.be>
2006-09-05 21:35 ` John David Anglin
  -- strict thread matches above, loose matches on Subject: below --
2006-08-30  4:48 Carlos O'Donell
2006-08-31  6:53 ` Grant Grundler
2006-08-31 18:52   ` Carlos O'Donell
2006-08-31 21:46     ` Grant Grundler
2006-09-03 14:54       ` Carlos O'Donell
2006-09-03 19:55         ` Grant Grundler
2006-09-03 20:29           ` James Bottomley
2006-09-03 20:30           ` Carlos O'Donell
2006-09-03 21:22             ` John David Anglin
2006-09-01 22:48   ` Grant Grundler
2006-09-01 22:59     ` Grant Grundler

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=20060904000937.GA6963@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=James.Bottomley@SteelEye.com \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=soete.joel@scarlet.be \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox