OOOOOOhhhh OK... I see what happened... I'm messing up myself basically. When I was at MIPS we kept a different tree than from M5-dev. So when I merged in the new code from when I was at MIPS, I basically overwrote the 'SerializeAfter' change for the O3 model. And since there wasnt (and still isnt!) any o3-mips regression then that slipped in the cracks that that flag had been updated....
With this coding push, hopefully we can fix that though. Nothing worse than re-coding something you already had working! On Tue, Apr 14, 2009 at 3:46 PM, Steve Reinhardt <ste...@gmail.com> wrote: > I vaguely recall that at some point the single IsSerializing flag got > replaced by the SerializeBefore and SerializeAfter flags to provide a little > more fine-grain control... some instructions just need one or the other and > some need both. > > Now that I've looked at 'hg annotate', your name is on the changeset that > added these! In fact, SeralizeBefore and Serialize after were added in > addition to (not in place of) IsSerializing, and the isSerializing() method > will return true if any of these three flags are set (though there are > separate isSerializeBefore() and isSerializeAfter() methods now too). This > seems confusing to me: I think IsSerializing should be eliminated, and > instructions marked IsSerializing should have one or both of the > Before/After flags set. The status quo could be a problem; for example, if > O3 checks isSerializeBefore() and isSerializeAfter() but never checks > isSerializing(), then an instruction marked IsSerializing will never > actually serialize. > > Steve > > > > On Tue, Apr 14, 2009 at 11:17 AM, Korey Sewell <ksew...@umich.edu> wrote: > >> Thanks for the insight. >> >> Looks like O3 has moved from squashing after system call to marking a the >> "SerializeAfter" flag for system calls. >> >> MIPS had system calls marked as "IsSerializing" which (from grep'ing >> around) happens to be a flag that isn't even used in the code anymore >> (delete?!). >> >> >> >> On Tue, Apr 14, 2009 at 1:57 PM, Steve Reinhardt <ste...@gmail.com>wrote: >> >>> The syscall instruction is marked as serializing, and it's up to the CPU >>> model to look at that flag and do whatever (if anything) is necessary to >>> make sure that any register or memory changes that happen in the syscall are >>> seen by the subsequent instructions--typically this means flush the >>> pipeline, if there is one. >>> >>> As far as modeling a latency, the time required for a syscall will vary >>> by many orders of magnitude depending on what the syscall does, and other >>> effects like icache and dcache pollution of the kernel code that's execute >>> are basically impossible to estimate. So the answer is that if you really >>> care about syscall overheads, use FS mode. Trying to do anything at all to >>> make syscall overhead more accurate in SE mode is really pointless at best, >>> and misleading at worst (IMO). >>> >>> The difference with TLB overheads is that they're needed to more >>> accurately model the execution time of the user code as well, so leaving >>> them out is a more fundamental issue with respect to the things that SE mode >>> is actually designed to get right. >>> >>> Steve >>> >>> On Tue, Apr 14, 2009 at 10:38 AM, Korey Sewell <ksew...@umich.edu>wrote: >>> >>>> I'm pretty sure that was in the code a while back, but I can not locate >>>> this currently in O3. Has this been removed? >>>> >>>> In SE mode, I would think squashing after a system call is necessary >>>> because real system calls would need to save/restore context to Memory >>>> before returning to user-mode execution since the OS would naturally use >>>> the >>>> context on the CPU to service the syscall. M5 in SE mode just models that >>>> the register return values get set correctly. >>>> >>>> However, in O3 speculative execution, there is no dependency kept >>>> between what registers a system call might update and the next PC counters >>>> of the system call. >>>> >>>> It would probably be unrealistic to keep that type of dependency in the >>>> 1st place, so I'm wondering how does SE mode work for other ISAs if we >>>> aren't squashing after system calls? Or are we just lucky there? >>>> >>>> And lastly, since we are incorporating timing for events like TLB >>>> translation in SE mode wouldnt it also make sense to have some default >>>> latency for system calls as well? >>>> >>>> -- >>>> ---------- >>>> Korey L Sewell >>>> Graduate Student - PhD Candidate >>>> Computer Science & Engineering >>>> University of Michigan >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> ---------- >> Korey L Sewell >> Graduate Student - PhD Candidate >> Computer Science & Engineering >> University of Michigan >> >> _______________________________________________ >> 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 > > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
