Let me correct my english, sorry: Serialization of Store Conditionals is one issue, at this point I am unable to determine whether the issue is M5 Alpha implementation or just that the Alpha ISA is too old. I tried seeing what other architecture do, but there is not an LL/SC in Intel implementation (they use a lock prefit tag on each instruction).
On Mon, Dec 7, 2009 at 5:03 PM, ef <[email protected]> wrote: > Hello, > > I have been doing some research on PARSEC and M5. There seems to be a lot > of serialization causing bad IPC in Parsec Benchmarks. Serialization of > Store Conditionals is ne issue, at this point I am unable to determine > whether the issue is M5 Alpha implementation or just that the Alpha ISA is > to old. I tried seeing what other architecture do, but there are LL/SC in > Intel implemtations (they use a lock prefit tag on each instruction). > > If it turns out that we dont need to make LL/SC unserial, any possible > ideas on solutions? Although I am not sure thats the case, I just had > difficulty finding literature in terms of alpha with LL/SC. > > Here is what I am talking about: > cpu/o3/rename_impl.hh > Line 649: > > // Handle serializeAfter/serializeBefore instructions. > // serializeAfter marks the next instruction as serializeBefore. > // serializeBefore makes the instruction wait in rename until the > ROB > // is empty. > > // In this model, IPR accesses are serialize before > // instructions, and store conditionals are serialize after > // instructions. This is mainly due to lack of support for > // out-of-order operations of either of those classes of > // instructions. > if ((inst->isIprAccess() || inst->isSerializeBefore()) && > !inst->isSerializeHandled()) { > DPRINTF(Rename, "Serialize before instruction encountered.\n"); > > if (!inst->isTempSerializeBefore()) { > renamedSerializing++; > inst->setSerializeHandled(); > } else { > renamedTempSerializing++; > } > > // Change status over to SerializeStall so that other stages > know > // what this is blocked on. > renameStatus[tid] = SerializeStall; > > serializeInst[tid] = inst; > > blockThisCycle = true; > > break; > } else if ((inst->isStoreConditional() || inst->isSerializeAfter()) > && > !inst->isSerializeHandled()) { > DPRINTF(Rename, "Serialize after instruction encountered.\n"); > > renamedSerializing++; > > inst->setSerializeHandled(); > > serializeAfter(insts_to_rename, tid); > } > > > Thanks, > EF > > > > > > On Wed, Dec 2, 2009 at 11:40 AM, Steve Reinhardt <[email protected]> wrote: > >> Good question... it's not clear they need to be. I think the overall >> motivation is to make sure that lock acquire/release operations are >> properly ordered, but for Alpha that should be enforced via separate >> barrier instructions anyway. I assume this is happening as a side >> effect of the instructions being marked as "locked"? Can you point to >> the code you're referring to? >> >> Steve >> >> On Wed, Nov 18, 2009 at 7:03 PM, ef <[email protected]> wrote: >> > Hello, >> > Why are stl_c and stq_c serializing instructions in the O3 model >> > during the renaming stage? >> > >> > Thanks >> > EF >> > _______________________________________________ >> > m5-users mailing list >> > [email protected] >> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
