In the drmemtrace scheduler, some sort of full control over which replayed core should be which output stream would be good, as the comment in read_traced_schedule() says:
// We initially number the outputs according to their order in the file.
// XXX i#5843: Should we support some direction from the user on this? Simulation
// may want to preserve the NUMA relationships and may need to set up its simulated
// cores at init time, so it would prefer to partition by output stream identifier.
// Maybe we could at least add the proposed memtrace_stream_t query for cpuid and
// let it be called even before reading any records at all?
As a first step, we should at least sort the cpuids, as raw2trace inserts them in whatever hashtable order they were in, which is essentially random. E.g., on 2 sockets, the order for one trace has the 2 sockets completely intermixed: 4185,70,4207,4126,4129,69,... (the top bit 4096 marks the 2nd socket). This means the replay will not match the original order.
In the drmemtrace scheduler, some sort of full control over which replayed core should be which output stream would be good, as the comment in read_traced_schedule() says:
As a first step, we should at least sort the cpuids, as raw2trace inserts them in whatever hashtable order they were in, which is essentially random. E.g., on 2 sockets, the order for one trace has the 2 sockets completely intermixed: 4185,70,4207,4126,4129,69,... (the top bit 4096 marks the 2nd socket). This means the replay will not match the original order.