It should be easy enough to measure the latency of a pause on a real machine, but given the description and its purpose of avoiding memory order violations, my guess is that the latency is in the 10s of ns, possibly 100s.
That said, you should probably figure out a way to skip the function entirely and save the time. In fact, it might be worthwhile to search for pause in the code and skip all such functions. Nate > Hey everybody. I'm currently waiting on x86 to boot under gdb where I'm > occasionally stepping in to see what it's doing. It's spinning furiously in > a tight, three instruction loop while it calibrates the local APIC timer. > These instructions are: > > pause > cmpl $0x19,0x2860b(%rip) # 0xffffffff80903438 > jle 0xffffffff808dae24 <setup_boot_APIC_clock+142> > > > The second instruction checks to see if the loop can exit and the third is > the jump back to the top. The first instruction, "pause", is supposed to > make the CPU hang out briefly where "briefly" is a small, possibly zero, > delay. For us, this could make M5 boot X86 faster because it means fewer > instructions would be executed waiting for timer interrupts and in other > delay loops. > > I think the quiescCycles pseudo op function would make implementing this > behavior pretty easy, but then the question is how many cycles to wait. Does > anyone have an informed (but not too informed) opinion about what an > appropriate number of cycles would be? > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
