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
next prev parent 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 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.