Re: [Patch V2] Oprofile-testsuite, handle power-savings-mode changes during scaling test
Will Schmidt <[email protected]>
| Newsgroups | gmane.linux.oprofile |
|---|---|
| Message-ID | <1422645784.29696.59.camel@brimstone> |
On Mon, 2015-01-12 at 13:50 -0600, Will Schmidt wrote: > On Mon, 2015-01-12 at 10:59 -0500, William Cohen wrote: > > On 01/08/2015 01:53 PM, Will Schmidt wrote: > > > The scaling tests will fail if the power-savings-mode changes while the > > > test is running. (idle/slow <-> non-idle/fast). > > > This adds some logic to check the power state before and after running > > > the ocount scaling workload, and reruns the workload if the state has > > > changed before it attempts to process results. > > > > Hi Will, > > There is one typo in what I posted below, (sleep delay was too short), > so there will be a V3 of this patch, but in the mean-time.. > V3 following momentarily, only change wrt/V2 is the sleep delay adjustment. Additional chatter below. > > > > Aren't other processors such as x86 going to have similar issues as they change clock frequency? > > Possibly, but maybe not. My best guess to why it's not been an issue in > the past is that non-ppc platforms are making the frequency change quick > enough (within the initial 10 second window for $workload_exec to reach > steady state), that they just don't hit this scenario. My experimentation with a few x86* systems I've got access to are confirming for me that the frequency changes have settled before the test gets as far as the measuring stage, so this would seem to be an issue only for ppc64 (due to the multi-second delay in power mode changes). I'll note that I was able to force a failure on x86* by directly dropping the processor frequency during the critical time period, but I don't consider that typical behavior. > > Would it be possible make this portable to other architectures in addition to the ppc64? > > Yes. I can poke at this some on x86 and see if I can confirm my guess > from above. If not, I'll see what I can whip up. So I'm going with a 'no', I don't believe that is necessary. If we want the utility function names to be changed to something ppc64 specific, that would be reasonable, though I'd need input on what to change them to. :-) And all that said, I'm happy to revisit if anyone sees this fail on another architecture. Thanks, -Will ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/