From: Arnd Bergmann <arnd@arndb.de>
To: Carl Love <cel@us.ibm.com>
Cc: linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org,
oprofile-list@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch
Date: Thu, 15 Feb 2007 22:03:59 +0100 [thread overview]
Message-ID: <200702152203.59902.arnd@arndb.de> (raw)
In-Reply-To: <1171570918.31179.36.camel@dyn9047021078.beaverton.ibm.com>
On Thursday 15 February 2007 21:21, Carl Love wrote:
> I have done some quick measurements. =A0The above method limits the loop
> to at most 2^16 iterations. =A0Based on running the algorithm in user
> space, it takes about 3ms of computation time to do the loop 2^16 times.
>=20
> At the vary least, we need to put the resched in say every 10,000
> iterations which would be about every 0.5ms. =A0Should we do a resched
> more often? =A0
Yes, just to be on the safe side, I'd suggest to do it every 1000
iterations.
=20
> Additionally we could up the size of the table to 512 which would reduce
> the maximum time to about 1.5ms. =A0What do people think about increasing
> the table size?
No, that won't help too much. I'd say 256 or 128 entries is the most
we should have.
> As for using a logarithmic spacing of the precomputed values, this
> approach means that the space between the precomputed values at the high
> end would be much larger then 2^14, assuming 256 precomputed values.
> That means it could take much longer then 3ms to get the needed LFSR
> value for a large N. =A0By evenly spacing the precomputed values, we can
> ensure that for all N it will take less then 3ms to get the value.
> Personally, I am more comfortable with a hard limit on the compute time
> then a variable time that could get much bigger then the 1ms threshold
> that Arnd wants for resched. =A0Any thoughts?
When using precomputed values on a logarithmic scale, I'd recommend
just rounding to the closest value and accepting the relative inaccuracy,
instead of using the precomputed value as the base and then calculating
from there.
Arnd <><
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Carl Love <cel@us.ibm.com>
Cc: cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org,
oprofile-list@lists.sourceforge.net
Subject: Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch
Date: Thu, 15 Feb 2007 22:03:59 +0100 [thread overview]
Message-ID: <200702152203.59902.arnd@arndb.de> (raw)
In-Reply-To: <1171570918.31179.36.camel@dyn9047021078.beaverton.ibm.com>
On Thursday 15 February 2007 21:21, Carl Love wrote:
> I have done some quick measurements. The above method limits the loop
> to at most 2^16 iterations. Based on running the algorithm in user
> space, it takes about 3ms of computation time to do the loop 2^16 times.
>
> At the vary least, we need to put the resched in say every 10,000
> iterations which would be about every 0.5ms. Should we do a resched
> more often?
Yes, just to be on the safe side, I'd suggest to do it every 1000
iterations.
> Additionally we could up the size of the table to 512 which would reduce
> the maximum time to about 1.5ms. What do people think about increasing
> the table size?
No, that won't help too much. I'd say 256 or 128 entries is the most
we should have.
> As for using a logarithmic spacing of the precomputed values, this
> approach means that the space between the precomputed values at the high
> end would be much larger then 2^14, assuming 256 precomputed values.
> That means it could take much longer then 3ms to get the needed LFSR
> value for a large N. By evenly spacing the precomputed values, we can
> ensure that for all N it will take less then 3ms to get the value.
> Personally, I am more comfortable with a hard limit on the compute time
> then a variable time that could get much bigger then the 1ms threshold
> that Arnd wants for resched. Any thoughts?
When using precomputed values on a logarithmic scale, I'd recommend
just rounding to the closest value and accepting the relative inaccuracy,
instead of using the precomputed value as the base and then calculating
from there.
Arnd <><
next prev parent reply other threads:[~2007-02-15 21:03 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 23:52 [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch Carl Love
2007-02-15 14:37 ` Arnd Bergmann
2007-02-15 14:37 ` Arnd Bergmann
2007-02-15 16:15 ` Maynard Johnson
2007-02-15 16:15 ` Maynard Johnson
2007-02-15 18:13 ` Arnd Bergmann
2007-02-15 18:13 ` Arnd Bergmann
2007-02-15 20:21 ` Carl Love
2007-02-15 20:21 ` Carl Love
2007-02-15 21:03 ` Arnd Bergmann [this message]
2007-02-15 21:03 ` Arnd Bergmann
2007-02-15 21:50 ` Paul E. McKenney
2007-02-15 21:50 ` Paul E. McKenney
2007-02-16 0:33 ` Arnd Bergmann
2007-02-16 0:33 ` Arnd Bergmann
2007-02-16 0:32 ` Maynard Johnson
2007-02-16 0:32 ` Maynard Johnson
2007-02-16 17:14 ` Arnd Bergmann
2007-02-16 17:14 ` Arnd Bergmann
2007-02-16 21:43 ` Maynard Johnson
2007-02-16 21:43 ` Maynard Johnson
2007-02-18 23:18 ` Maynard Johnson
2007-02-18 23:18 ` Maynard Johnson
-- strict thread matches above, loose matches on Subject: below --
2007-02-22 0:02 Carl Love
2007-02-26 23:50 ` Arnd Bergmann
2007-02-26 23:50 ` Arnd Bergmann
2007-02-27 1:31 ` Michael Ellerman
2007-02-27 1:31 ` Michael Ellerman
2007-02-27 16:52 ` Maynard Johnson
2007-02-27 16:52 ` Maynard Johnson
2007-02-28 1:44 ` Arnd Bergmann
2007-02-28 1:44 ` Arnd Bergmann
2007-02-06 0:28 [RFC,PATCH] CELL PPU " Carl Love
2007-02-06 23:02 ` [Cbe-oss-dev] [RFC, PATCH] CELL " Carl Love
2007-02-06 23:02 ` Carl Love
2007-02-07 15:41 ` Maynard Johnson
2007-02-07 15:41 ` Maynard Johnson
2007-02-07 22:48 ` Michael Ellerman
2007-02-07 22:48 ` Michael Ellerman
2007-02-08 15:03 ` Maynard Johnson
2007-02-08 15:03 ` Maynard Johnson
2007-02-08 14:18 ` Milton Miller
2007-02-08 14:18 ` Milton Miller
2007-02-08 17:21 ` Arnd Bergmann
2007-02-08 17:21 ` Arnd Bergmann
2007-02-08 18:01 ` Adrian Reber
2007-02-08 18:01 ` Adrian Reber
2007-02-08 22:51 ` Carl Love
2007-02-08 22:51 ` Carl Love
2007-02-09 2:46 ` Milton Miller
2007-02-09 2:46 ` Milton Miller
2007-02-09 16:17 ` Carl Love
2007-02-09 16:17 ` Carl Love
2007-02-11 22:46 ` Milton Miller
2007-02-11 22:46 ` Milton Miller
2007-02-12 16:38 ` Carl Love
2007-02-12 16:38 ` Carl Love
2007-02-09 18:47 ` Milton Miller
2007-02-09 18:47 ` Milton Miller
2007-02-09 19:10 ` Arnd Bergmann
2007-02-09 19:10 ` Arnd Bergmann
2007-02-09 19:46 ` Milton Miller
2007-02-09 19:46 ` Milton Miller
2007-02-08 23:59 ` Maynard Johnson
2007-02-08 23:59 ` Maynard Johnson
2007-02-09 18:03 ` Milton Miller
2007-02-09 18:03 ` Milton Miller
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=200702152203.59902.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cbe-oss-dev@ozlabs.org \
--cc=cel@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=oprofile-list@lists.sourceforge.net \
/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.