From: Grant Grundler <grundler@parisc-linux.org>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: dave.anglin@nrc-cnrc.gc.ca, linux-parisc@vger.kernel.org
Subject: Re: [parisc] [PATCH] timer_interrupt: Fix "SLOW!" warning on rp3440
Date: Sun, 13 Mar 2011 19:50:58 -0600 [thread overview]
Message-ID: <20110314015058.GE29986@parisc-linux.org> (raw)
In-Reply-To: <20110314012235.229C64FDB@hiauly1.hia.nrc.ca>
On Sun, Mar 13, 2011 at 09:22:34PM -0400, John David Anglin wrote:
...
> > Hi Dave,
> > Maybe the patch should be for this line of code instead?
> > if (unlikely(now2 - now > 0x3000)) /* 12K cycles */
> >
> > ie increase the value slightly?
>
> I tried that initially. After bumping it a couple of times, it
> seemed like more iterations in the `if' alternative was better as
> most instructions only take one cycle. My sense is that we only
> exceed the current limit in rare circumstances.
Ok. If your patch avoids the case, then it's certainly worth entertaining.
> > TBH, I didn't spend alot of time trying to figure out the optimal balance
> > between the two cases that the proposed patch attempts to adjust.
> >
> > Also, if the div/mul takes up to 0x7000 cycles, another alternative
> > is to make the alternative faster. What I suggested in the else case:
> > /* TODO: Reduce this to one fdiv op */
> >
> > doesn't seem possible with fdiv in one op. My reading of the fdiv
> > operator suggests it would need another FMUL and FSUB op in order
> > to get the remainder. Still might be vary fast.
> >
> > Looking through PA 2.0 arch book, looks like the PA2.0
> > "Divide Step" (DS) operation (page 7-46) does what I was thinking of.
> > But that's going to require a sequence of DS instructions that
> > I don't quite understand at the moment and thus can't say how
> > fast the worst case for DS might be.
>
> Currently, I believe that the kernel does integer multiplication
> and division using millicode. If I remember correctly, division
> uses the DS instruction. The situation is worse for 64-bit operations
> because HP never released their 64-bit millicode code. So, gcc does
> long division in this case.
The URL I provided in other reply:
http://www.cs.bham.ac.uk/research/projects/poplog/src/master/C.hppa/src/aarith.s
implemented 64-bit/32-bit math. Should be easy to integrate.
> I haven't seen any SLOW warnings with the patch I suggested but it
> may be a bit inefficient. I have the sense that the problem occurs
> on the rp3440 because it has two dual core cpus. I have never seen
> the warning on machines with a single processor chip.
The dual core might be competing for a shared resource related to FP?
I don't know either. But if your patch avoids the warning, I'd say apply
it until someone else cares enough to integrate the 64-bit divU and
make use of it here.
cheers,
grant
next prev parent reply other threads:[~2011-03-14 1:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-12 17:08 [parisc] [PATCH] timer_interrupt: Fix "SLOW!" warning on rp3440 John David Anglin
2011-03-12 20:59 ` James Bottomley
2011-03-12 23:36 ` John David Anglin
2011-03-13 23:58 ` Grant Grundler
2011-03-14 1:22 ` John David Anglin
2011-03-14 1:50 ` Grant Grundler [this message]
2011-03-14 2:16 ` John David Anglin
2011-03-14 1:44 ` 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=20110314015058.GE29986@parisc-linux.org \
--to=grundler@parisc-linux.org \
--cc=dave.anglin@nrc-cnrc.gc.ca \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=linux-parisc@vger.kernel.org \
/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.