I just confirmed that SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing includes a brk() call that tries to shrink the heap, which with the old obreakFunc() triggers the ChunkGenerator assertion I added.
It turns out that in the old broken code if the previous break val was at a page boundary (so that everything up to but not including that page was allocated) and then you lowered the break, then the code would allocate a new page at the old break val anyway (since it assumed that you were increasing the break). So I think what happened is that in the old bogus code the page allocation was slightly different, which would lead to different physical addresses and thus different cache conflicts. So if it was just a timing difference I'd be fine with that, but the instruction count changed too, so I'll poke at it a little more and see if there's something else going on. Steve On Mon, Nov 17, 2008 at 12:51 AM, Gabe Black <[EMAIL PROTECTED]> wrote: > Nope, it wasn't me. It was changeset f28f020f3006, syscalls: fix latent > brk/obreak bug. > > Gabe > > Gabe Black wrote: >> Unless it's the second change where I refactored my code. That's during >> the time with the assertion bug. >> >> Gabe >> >> Gabe Black wrote: >> >>> I don't think this is me, actually. I ran it for each changeset starting >>> from right before my timing simple CPU changes, and it's worked each >>> time up until that assertion bug from Steve. That wasn't fixed until >>> just recently, I think, so finding where it starts failing beyond that >>> might be annoying. I won't be working on it any more tonight, but if I >>> get a chance over the next week I'll see if I can figure it out. >>> >>> Gabe >>> >>> Gabe Black wrote: >>> >>> >>>> I just ran it myself, and the number of instructions is exactly the same >>>> so it's probably not anything like a syscall where it would change the >>>> path of execution. It's probably because my change to the the CPU caused >>>> the timing of some corner case to change slightly, hopefully not because >>>> of a memory error although I wouldn't rule it out. Fortunately it seems >>>> to be a reproducible failure, which is surprising since I ran >>>> regressions more than once, so it'll hopefully be easy to pin down. >>>> >>>> Gabe >>>> >>>> nathan binkert wrote: >>>> >>>> >>>> >>>>> Though the fact that a TimingSimpleCPU test failed is a bit suspicious >>>>> since it didn't in the past and you just modified it. >>>>> >>>>> Nate >>>>> >>>>> On Sun, Nov 16, 2008 at 8:45 PM, nathan binkert <[EMAIL PROTECTED]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> My guess is that it's an uninitialized variable. My further guess is >>>>>> that it's related to some specific system call since it only happens >>>>>> in SE mode. >>>>>> >>>>>> Nate >>>>>> >>>>>> On Sun, Nov 16, 2008 at 8:29 PM, Gabe Black <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> parser seems to have a long standing and hard to identify problem where >>>>>>> it changes a little bit every now and then for no apparent reason. I'm >>>>>>> not sure what would be the problem with SPARC. Did the disk image change >>>>>>> recently? Which one does that regression use? >>>>>>> >>>>>>> Gabe >>>>>>> >>>>>>> nathan binkert wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> That's odd. I just ran it and it worked fine. The ones I just had >>>>>>>> fail are: >>>>>>>> SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing >>>>>>>> X86_SE/tests/opt/long/20.parser/x86/linux/simple-timing >>>>>>>> >>>>>>>> They differ in about the same way from the base stats. >>>>>>>> >>>>>>>> Are you sure you have the right disk image? >>>>>>>> >>>>>>>> Nate >>>>>>>> >>>>>>>> On Sun, Nov 16, 2008 at 8:17 PM, Gabe Black <[EMAIL PROTECTED]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I've significantly reworked the ide controller device, and while >>>>>>>>> running the regressions to test it out I noticed that >>>>>>>>> build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3/ is >>>>>>>>> failing even in the head. I tried it out with a slightly older version >>>>>>>>> of the head, updated and tried it out with my changes in place, and >>>>>>>>> now >>>>>>>>> I'm trying out just a clean and up to head, but it seems to >>>>>>>>> consistently >>>>>>>>> fail with slightly different stats in the o3. Is this something that >>>>>>>>> the >>>>>>>>> o3 serialization/unserialization changes would have done? >>>>>>>>> >>>>>>>>> Gabe >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >> > > _______________________________________________ > 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
