I manually ran a scratch quick regression and everything looks OK. (Had to do a scratch anyway for those protocol changes to take effect... otherwise we'd have to wait until next weekend.)
Steve On Mon, Feb 1, 2010 at 11:20 AM, Beckmann, Brad <brad.beckm...@amd.com> wrote: > Yeah, I didn't realize that default protocol had changed. I just pushed a > changeset to revert it back to MI_example. > > Sure, we can run the non-ruby tests on all ruby protocols. As long as it > doesn't increase the testing time beyond a reasonable level, there is no harm > in doing so. > > Brad > > > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of > Steve Reinhardt > Sent: Monday, February 01, 2010 8:55 AM > To: M5 Developer List > Subject: Re: [m5-dev] Cron > <m5t...@zizzer>/z/m5/regression/do-regression--scratch all > > Yes, it would... that would be great. I think having the option to > compile out the classic M5 memory hierarchy is still useful, but > that's only a partial solution to the current problem. > > Steve > > On Mon, Feb 1, 2010 at 8:49 AM, nathan binkert <n...@binkert.org> wrote: >> I'll see if I can put a little bit of effort into allowing multiple >> protocols to be compiled into the same binary. That would really fix >> the problem, right? >> >> Nate >> >> On Mon, Feb 1, 2010 at 8:46 AM, Steve Reinhardt <ste...@gmail.com> wrote: >>> OK, I realize the idea I was originally thinking of didn't solve the >>> problem of not wanting to rerun all the non-ruby tests on every >>> different ruby protocol build. >>> >>> For those following at home (prob. everyone other than Brad and me), >>> the issue is that the test infrastructure is designed to run every >>> test that applies to a given binary, but with N different ruby >>> protocol builds, you end up running all of the ruby-independent tests >>> N times even though it should be sufficient to run them once. Brad's >>> solution only runs the ruby-independent tests on the build that uses >>> the "default" ruby protocol. However, that default protocol is >>> hard-coded in the test script, and when the actual default protocol >>> gets changed but the test script is not updated, then you end up not >>> running any ruby-independent tests (which is what has been happening >>> lately). >>> >>> Ideally I'd like to stay with the model of running every test on every >>> binary it applies to; while the current solution optimizes some >>> unnecessary tests out of the full regression, it also eliminates some >>> potentially useful tests for people who might not be using the default >>> ruby protocol. One option that I'm leaning toward is to add a scons >>> flag to disable compiling in the "classic" M5 cache model. Then we >>> can disable it in all but one of the ruby builds, and not run any >>> tests that require the classic M5 memory hierarchy for those builds. >>> That would still leave us running the purely functional tests (that >>> really don't require a cache hierarchy at all) on all of the different >>> ruby protocol builds, but I don't think any of those are very long, so >>> that shouldn't be so bad to put up with. >>> >>> Steve >>> >>> On Sun, Jan 31, 2010 at 10:53 PM, Steve Reinhardt <ste...@gmail.com> wrote: >>>> I'm not sure it's the stickiness... my interpretation is that Derek >>>> changed the default in the src/mem/protocol/SConsopts file which made >>>> it inconsistent with what you assumed it was in tests/SConscript. >>>> Anyway, I think the fix I suggested that completely removes any >>>> dependence on the default value in the test system is more robust and >>>> what we should do in the long run. >>>> >>>> Steve >>>> >>>> On Sun, Jan 31, 2010 at 10:33 PM, Beckmann, Brad <brad.beckm...@amd.com> >>>> wrote: >>>>> Yep, the problem is the PROTOCOL variable is sticky and therefore isn't >>>>> being set to the default. >>>>> >>>>> I just pushed a fix to add the default PROTOCOL variable to all build_opt >>>>> files. That should fix the regression tester, but it would be nice to >>>>> always set the PROTOCOL variable to the default unless explicitly >>>>> specified at the command line. >>>>> >>>>> Brad >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On >>>>> Behalf Of Steve Reinhardt >>>>> Sent: Sunday, January 31, 2010 4:40 PM >>>>> To: M5 Developer List >>>>> Subject: Re: [m5-dev] Cron <m5t...@zizzer> >>>>> /z/m5/regression/do-regression--scratch all >>>>> >>>>> OK, I believe it's a problem Brad was already worried about... see this: >>>>> >>>>> diff -r a162a2b0b1f8 -r 5bd33f7c26ea tests/SConscript >>>>> --- a/tests/SConscript Fri Jan 29 20:29:34 2010 -0800 >>>>> +++ b/tests/SConscript Fri Jan 29 20:29:40 2010 -0800 >>>>> @@ -264,11 +264,23 @@ >>>>> else: >>>>> configs += ['simple-atomic', 'simple-timing', 'o3-timing', 'memtest', >>>>> 'simple-atomic-mp', 'simple-timing-mp', 'o3-timing-mp', >>>>> - 'inorder-timing'] >>>>> + 'inorder-timing', 'rubytest'] >>>>> >>>>> if env['RUBY']: >>>>> - # Hack for Ruby >>>>> - configs += [c + '-ruby' for c in configs] >>>>> + # With Ruby, A protocol must be specified in the environment >>>>> + assert(env['PROTOCOL']) >>>>> + >>>>> + # >>>>> + # Is there a way to determine what is Protocol EnumVariable >>>>> + # default and eliminate the need to hard code the default protocol >>>>> below? >>>>> + # >>>>> + # If the binary includes the default ruby protocol, run both ruby and >>>>> + # non-ruby versions of the tests. Otherwise just run the ruby >>>>> versions. >>>>> + # >>>>> + if env['PROTOCOL'] == 'MI_example': >>>>> + configs += [c + "-ruby" for c in configs] >>>>> + else: >>>>> + configs = [c + "-ruby-" + env['PROTOCOL'] for c in configs] >>>>> >>>>> cwd = os.getcwd() >>>>> os.chdir(str(Dir('.').srcdir)) >>>>> >>>>> and then compare with this change, which is from Derek's merge changeset: >>>>> >>>>> diff -r 289ac904233d -r 3d308cbd1657 src/mem/protocol/SConsopts >>>>> --- a/src/mem/protocol/SConsopts Wed Nov 18 18:00:41 2009 -0800 >>>>> +++ b/src/mem/protocol/SConsopts Tue Jan 19 15:48:12 2010 -0600 >>>>> @@ -50,7 +50,7 @@ >>>>> 'MOESI_hammer', >>>>> ] >>>>> >>>>> -opt = EnumVariable('PROTOCOL', 'Coherence Protocol for Ruby', >>>>> 'MI_example', >>>>> +opt = EnumVariable('PROTOCOL', 'Coherence Protocol for Ruby', >>>>> 'MOESI_CMP_directory', >>>>> all_protocols) >>>>> >>>>> >>>>> ... so that mismatch is causing all the builds that use the default >>>>> Ruby protocol to not find any applicable configurations since >>>>> tests/SConscript is looking for a different default protocol. >>>>> >>>>> I think the best way to fix this is to forget trying to have the test >>>>> configs track the 'default' Ruby protocol, but instead to always have >>>>> the protocol explicit in the config name. This will require moving >>>>> the existing *-ruby reference outputs, but it's more stable in the >>>>> long run. Brad and I can probably discuss this tomorrow and make it >>>>> happen. >>>>> >>>>> Steve >>>>> >>>>> 2010/1/31 Steve Reinhardt <ste...@gmail.com>: >>>>>> I'm looking at it now... I'm not sure exactly what the error is, but it >>>>>> looks like it's running *only* the ruby tests now, and acting like the >>>>>> non-ruby tests don't exist. >>>>>> >>>>>> Steve >>>>>> >>>>>> On Sun, Jan 31, 2010 at 11:24 AM, Beckmann, Brad <brad.beckm...@amd.com> >>>>>> wrote: >>>>>>> I agree, I don't think it is working correctly. I don't have access to >>>>>>> the Michigan server and I can't reproduce the error. Could someone send >>>>>>> out the do-regression script? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brad >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> m5-dev@m5sim.org >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> m5-dev@m5sim.org >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>> >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
