On Tue, Jan 10, 2012 at 12:32 PM, Addison Mayberry <[email protected]>wrote:
> Of course. The function I've been using to dump memory was written by a
> former member of my group, so if there are questions about how it works
> I'll probably need to get in touch with him to ask. Here's the code:
>
> void dump_pmem(const char * name)
> {
> FILE *f;
> uint32_t l;
> uint8_t buf[1024];
> Monitor *mon = cur_mon;
> uint32_t size = 1024 * 1024 * 1024; // Using a 1GB memory
> const char *filename = name;
> target_phys_addr_t addr = 0x0;
>
> f = fopen(filename, "wb");
> if (!f) {
> monitor_printf(mon, "could not open '%s'\n", filename);
> return;
> }
> while (size != 0) {
> l = sizeof(buf);
> if (l > size)
> l = size;
> cpu_physical_memory_rw(addr, buf, l, 0);
> fwrite(buf, 1, l, f);
> fflush(f);
> addr += l;
> size -= l;
> }
> fclose(f);
> }
>
> To make the dump, I modified the beginning of ptl_check_ptlcall_queue() in
> ptl-qemu.cpp so it looks as follows:
>
> void ptl_check_ptlcall_queue() {
>
> if(pending_call_type != -1) {
>
> switch(pending_call_type) {
> case PTLCALL_ENQUEUE:
> {
> // Begin new code
> if (!strcmp(pending_command_str, "-run")) {
> cout << "Simulator about to start, dumping
> memory\n";
> char buffer[64];
> sprintf(buffer, "prestart-memdump");
> dump_pmem(buffer);
> }
> // End new code
>
> if (!config.quiet) cout << "MARSSx86::Command received
> : ",
> pending_command_str, endl;
> ptl_machine_configure(pending_command_str);
>
> This caused the simulator to create the memory dump file when the "-run"
> command was received. Once I had dump files from separate runs, as I
> mentioned before, I used the vbindiff tool (
> http://www.cjmweb.net/vbindiff/) to compare them. That's it in a
> nutshell, let me know if I can explain anything further.
>
> Thanks for the code and details. I'll try to run some of my checkpoints
to find these memory corruptions.
Avadh, you mentioned that you're wondering if it's a checkpointing issue.
> It's worth noting that I did a similar experiment where I dumped memory as
> soon as QEMU finished the checkpoint load operations (I added a call to
> dump_pmem at the end of load_vmstate in savevm.c), and every single dump
> from that location is exactly the same. So, I'm reasonably certain that
> QEMU always loads the memory in exactly the same state, which is why I'm
> pretty sure there's something going on between checkpoint load completing
> and the simulator starting. Please let me know if you figure anything out,
> I'll probably probe it a little further on my end.
>
In that case I don't have to debug in QEMU. I'll keep you updated if I
find something.
Thanks,
Avadh
>
> -Addison
>
>
> On 01/10/2012 01:13 PM, avadh patel wrote:
>
> This is a great find as we are also trying to find out some issues with
> checkpoints. I am not expert in QEMU so I have no idea what is restored
> when we continue execution from a checkpoint and do they modify and memory
> (like clock and some driver stats etc.). If you can share the method on
> how you collect your memory diffs then it will save lot of time in
> debugging.
>
> Thanks,
> Avadh
>
> On Tue, Jan 10, 2012 at 10:01 AM, Addison Mayberry
> <[email protected]>wrote:
>
>> I've been using a tool called VBinDiff (visual binary diff), so I can
>> see exactly where the files are different. The differences are relatively
>> small, only a few hundred bytes concentrated in a few areas. However, since
>> I'm relatively sure that my performance variations are stemming from
>> differences in memory state I don't want to ignore anything that might be
>> causing those differences (and also I'm just curious as to what's
>> happening.)
>>
>>
>> On 01/10/2012 11:27 AM, Paul Rosenfeld wrote:
>>
>> I don't know the answer to your question, but this is certainly a very
>> interesting experiment.
>>
>> Are you doing "different or same" comparison or do you have some sense
>> of how different the memory dumps are? Are we talking a few bytes or large
>> swaths of memory?
>>
>> On Tue, Jan 10, 2012 at 11:10 AM, Addison Mayberry <[email protected]
>> > wrote:
>>
>>> Greetings,
>>> I am trying do some detailed performance tests, and to get more
>>> consistent data I have been trying to weed out issues that cause variation
>>> in my results on repeated executions of the same program from the same
>>> image checkpoint. To that end I started doing some analysis on the
>>> following two lines of code being executed in the simulator:
>>>
>>> ptlcall_checkpoint_and_shutdown("connection-made");
>>> ptlcall_single_flush("-run");
>>>
>>> After which my benchmark code begins to run. I added code in PTLSim to
>>> do a dump of simulated physical memory when it receives the "-run"
>>> instruction, and comparing these dumps across multiple runs I found that
>>> they were different.
>>>
>>> I was aware that MARSS is not guaranteed (or expected) to have
>>> deterministic performance, but I was surprised that there would be
>>> variations in the execution over such a small period of time - between
>>> loading the checkpoint and then dropping into simulation. Does anyone have
>>> any thoughts on what might be causing the differences in memory state, and
>>> what I might be able to do to keep that from happening and make my tests
>>> more repeatable? Thanks for any insight.
>>> Sincerely,
>>> Addison
>>>
>>> _______________________________________________
>>> http://www.marss86.org
>>> Marss86-Devel mailing list
>>> [email protected]
>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>>
>>
>>
>>
>>
>> _______________________________________________
>> http://www.marss86.org
>> Marss86-Devel mailing list
>> [email protected]
>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
>>
>
>
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
