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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox