Hi Avadh,

After some more inspection, I think what I'm seeing is not the result of
any changes I'm making, but the result of
global_stats.ooocore.total.cycles getting incremented on every call of
flush_stats and global_stats.summary.cycles not being incremented in this
manner. I can reproduce this on a clean version of marss. I think I'm
seeing multiple calls to flush_stats because I'm doing a simconfig -stop
followed by a simconfig -kill.

Thanks
-matt

> Send Marss86-Devel mailing list submissions to
>       [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
> or, via email, send a message with subject or body 'help' to
>       [email protected]
>
> You can reach the person managing the list at
>       [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Marss86-Devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Snapshot Problem (avadh patel)
>    2. Re: Statistics show vaying cycle counts (avadh patel)
>    3. Re: Snapshot Problem (Timothy Hayes)
>    4. Re: Maximum QEMU/System memory size (DRAM Ninjas)
>    5. Re: Maximum QEMU/System memory size (Jason Clemons)
>    6. mesiBus: dataQueue never used? (DRAM Ninjas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Feb 2011 10:12:21 -0700
> From: avadh patel <[email protected]>
> To: Timothy Hayes <[email protected]>
> Cc: marss86-devel <[email protected]>
> Subject: Re: [marss86-devel] Snapshot Problem
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I fond the issue and its because the stats file was reopened every time
> configuration is changed !!
> I have attached a small patch that should fix this issue. I don't have a
> setup that call's ptlcall_capture_stats() function so can you please test
> this patch and confirm that this fixes the issue.
>
> Thanks,
> Avadh
>
> On Sat, Feb 12, 2011 at 1:37 PM, Timothy Hayes <[email protected]> wrote:
>
>> Hi,
>>
>> I'm trying to take a statistics snapshot before and after a particular
>> kernel but it is giving me problems.
>>
>> My code looks like this:
>> ---------------------------------------
>> ptlcall_capture_stats("pre");
>> // call to function
>> ptlcall_capture_stats("post");
>> ---------------------------------------
>>
>> My console shows me the following output:
>> ---------------------------------------
>>  Completed       2630000 cycles,        858781 commits:    459604 Hz,
>>  114181 insns/sec: rip ffffffff813594c1ptlcall_mmio_write: calltype 2
>> at rip 4196121 (inside_ptlsim = 1 )
>> PTLCALL type PTLCALL_ENQUEUE
>> MARSSx86::Command received : -snapshot-now pre
>> ptlcall_mmio_write: calltype 2 at rip 4196121 (inside_ptlsim = 1 )
>> PTLCALL type PTLCALL_ENQUEUE
>> MARSSx86::Command received : -snapshot-now post
>>  Completed       5825000 cycles,       1934160 commits:    428036 Hz,
>>   119043 insns/sec: rip ffffffff81100b35ptlcall_mmio_write: calltype
>> 2 at rip 4196905 (inside_ptlsim = 1 )
>> PTLCALL type PTLCALL_ENQUEUE
>> MARSSx86::Command received : -kill
>> ---------------------------------------
>>
>> The logfile has the following too:
>> ---------------------------------------
>> *snipped*
>> Start logging at level 0 in cycle 2689123
>> Making stats snapshot uuid 0 named pre at cycle 2690000
>> *snipped*
>> Start logging at level 0 in cycle 2691898
>> Completed       2692000 cycles,        890788 commits:    303511 Hz,
>>  156685 insns/sec: rip 000000000040cab6
>> Making stats snapshot uuid 0 named post at cycle 2692000
>> *snipped*
>> ---------------------------------------
>>
>> When I call ptlstats:
>> ---------------------------------------
>> ../ptlstats -snapshot pre ./kernel.stats
>> ptlstats: Cannot get snapshot 'pre'
>> ./ptlstats -snapshot post ./kernel.stats
>> ptlstats: Cannot get snapshot 'post'
>> ---------------------------------------
>>
>> There exists 3 snapshots in the stats file, but I don't believe they
>> are what I'm looking for:
>> ---------------------------------------
>> 1.
>>  snapshot_name = "user"; { (zero) }
>>  snapshot_uuid = 0; { (zero) }
>> 2.
>>  snapshot_name = "kernel"; { (zero) }
>>  snapshot_uuid = 1;
>> 3.
>>  snapshot_name = "global"; { (zero) }
>>  snapshot_uuid = 2;
>> ---------------------------------------
>>
>> I call my program as the website suggests
>> ---------------------------------------
>> ./start_sim; ./kernel ; ./kill_sim;
>> ---------------------------------------
>>
>> I'm using the latest MARSS 'master' branch in the GIT repository.
>>
>> I'd really appreciate if you could explain what's going on. Is this an
>> error on my part or a bug with MARSS? I want to do this so I can look
>> at the statistics of this function in isolation.
>>
>> Kind regards
>> Tim
>>
>> _______________________________________________
>> http://www.marss86.org
>> Marss86-Devel mailing list
>> [email protected]
>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110214/da222ba4/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: stats_reopen_fix.patch
> Type: application/octet-stream
> Size: 1128 bytes
> Desc: not available
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110214/da222ba4/attachment-0001.obj>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 14 Feb 2011 10:28:11 -0700
> From: avadh patel <[email protected]>
> To: Matthew Laquidara <[email protected]>
> Cc: [email protected]
> Subject: Re: [marss86-devel] Statistics show vaying cycle counts
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I checked some stats file and for me both summary/cycles and
> ooocore/total/cycles are same.
> Can you post the diff of your changes? From the code that updates both the
> counters seems correct.
>
> - Avadh
>
> On Sun, Feb 13, 2011 at 11:24 PM, DRAM Ninjas <[email protected]>
> wrote:
>
>> The summary you mean the print statement at the end of the logfile/std
>> out
>> when the simulation ends?
>>
>> I think Avadh has said that that print is deprecated and the stuff
>> that's
>> printed isn't necessarily right.
>>
>> On Sun, Feb 13, 2011 at 4:07 PM, Matthew Laquidara
>> <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> I'm curious about the cycle counts shown by the marss statistics. I'm
>>> running with a single core and 1 thread per core I'm getting very
>>> different cycle counts from summary/cycles vs. ooocore/total/cycles;
>>> the
>>> latter is consistently a little under 5 times the former. Furthermore,
>>> the
>>> former is close to the sum of the cycle counts in the kernel/user
>>> snapshots whereas the latter is not.
>>>
>>> I am wondering if I am misreading/misunderstanding something very
>>> fundamental or if something else is at work. I have the latest version
>>> of
>>> marss pulled from git and I have made some changes, but I don't see
>>> them
>>> as impacting statistics collection.
>>>
>>> Thank you very much.
>>> -matt
>>>
>>> _______________________________________________
>>> 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
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110214/b21cc05e/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 14 Feb 2011 19:05:28 +0100
> From: Timothy Hayes <[email protected]>
> To: avadh patel <[email protected]>
> Cc: marss86-devel <[email protected]>
> Subject: Re: [marss86-devel] Snapshot Problem
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Thank you, that patch appears to fix the problem although it has
> uncovered another one. I can't seem to get the -subtract argument to
> work for ptlstats.
>
> --
> ./ptlstats -snapshot post -subtract pre ./kernel.stats > isolated.txt
> ./ptlstats -snapshot post ./kernel.stats > post.txt
> ./ptlstats -snapshot pre ./kernel.stats > pre.txt
> --
>
> All these files should theoretically be different but isolated.txt and
> post.txt are exactly the same.
>
> Am I calling the tool wrong or is this a bug?
>
> Kind regards
> Tim
>
> On 14 February 2011 18:12, avadh patel <[email protected]> wrote:
>> Hi,
>> I fond the issue and its because the stats file was reopened every time
>> configuration is changed !!
>> I have attached a small patch that should fix this issue. I don't have a
>> setup that call's ptlcall_capture_stats() function so can you please
>> test
>> this patch and confirm that this fixes the issue.
>> Thanks,
>> Avadh
>>
>> On Sat, Feb 12, 2011 at 1:37 PM, Timothy Hayes <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to take a statistics snapshot before and after a particular
>>> kernel but it is giving me problems.
>>>
>>> My code looks like this:
>>> ---------------------------------------
>>> ptlcall_capture_stats("pre");
>>> // call to function
>>> ptlcall_capture_stats("post");
>>> ---------------------------------------
>>>
>>> My console shows me the following output:
>>> ---------------------------------------
>>> ?Completed ? ? ? 2630000 cycles, ? ? ? ?858781 commits: ? ?459604 Hz,
>>> ?114181 insns/sec: rip ffffffff813594c1ptlcall_mmio_write: calltype 2
>>> at rip 4196121 (inside_ptlsim = 1 )
>>> PTLCALL type PTLCALL_ENQUEUE
>>> MARSSx86::Command received : -snapshot-now pre
>>> ptlcall_mmio_write: calltype 2 at rip 4196121 (inside_ptlsim = 1 )
>>> PTLCALL type PTLCALL_ENQUEUE
>>> MARSSx86::Command received : -snapshot-now post
>>> ?Completed ? ? ? 5825000 cycles, ? ? ? 1934160 commits: ? ?428036 Hz,
>>> ? 119043 insns/sec: rip ffffffff81100b35ptlcall_mmio_write: calltype
>>> 2 at rip 4196905 (inside_ptlsim = 1 )
>>> PTLCALL type PTLCALL_ENQUEUE
>>> MARSSx86::Command received : -kill
>>> ---------------------------------------
>>>
>>> The logfile has the following too:
>>> ---------------------------------------
>>> *snipped*
>>> Start logging at level 0 in cycle 2689123
>>> Making stats snapshot uuid 0 named pre at cycle 2690000
>>> *snipped*
>>> Start logging at level 0 in cycle 2691898
>>> Completed ? ? ? 2692000 cycles, ? ? ? ?890788 commits: ? ?303511 Hz,
>>> ?156685 insns/sec: rip 000000000040cab6
>>> Making stats snapshot uuid 0 named post at cycle 2692000
>>> *snipped*
>>> ---------------------------------------
>>>
>>> When I call ptlstats:
>>> ---------------------------------------
>>> ../ptlstats -snapshot pre ./kernel.stats
>>> ptlstats: Cannot get snapshot 'pre'
>>> ./ptlstats -snapshot post ./kernel.stats
>>> ptlstats: Cannot get snapshot 'post'
>>> ---------------------------------------
>>>
>>> There exists 3 snapshots in the stats file, but I don't believe they
>>> are what I'm looking for:
>>> ---------------------------------------
>>> 1.
>>> ?snapshot_name = "user"; { (zero) }
>>> ?snapshot_uuid = 0; { (zero) }
>>> 2.
>>> ?snapshot_name = "kernel"; { (zero) }
>>> ?snapshot_uuid = 1;
>>> 3.
>>> ?snapshot_name = "global"; { (zero) }
>>> ?snapshot_uuid = 2;
>>> ---------------------------------------
>>>
>>> I call my program as the website suggests
>>> ---------------------------------------
>>> ./start_sim; ./kernel ; ./kill_sim;
>>> ---------------------------------------
>>>
>>> I'm using the latest MARSS 'master' branch in the GIT repository.
>>>
>>> I'd really appreciate if you could explain what's going on. Is this an
>>> error on my part or a bug with MARSS? I want to do this so I can look
>>> at the statistics of this function in isolation.
>>>
>>> Kind regards
>>> Tim
>>>
>>> _______________________________________________
>>> http://www.marss86.org
>>> Marss86-Devel mailing list
>>> [email protected]
>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
>>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Feb 2011 10:49:35 -0500
> From: DRAM Ninjas <[email protected]>
> To: Jason Clemons <[email protected]>, avadh patel
>       <[email protected]>
> Cc: marss86-devel <[email protected]>
> Subject: Re: [marss86-devel] Maximum QEMU/System memory size
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I'm sorry that I never got around to looking at this, but it turns out the
> error message was just meaningless. Essentially, if you ask for more than
> 3.5G of memory, QEMU leaves a hole between 3.5G and 4.0G and so some extra
> logic was required to determine if an address was actually out of bounds.
>
> Anyways, I've written a tiny patch and tested with both 4GB and 8GB and it
> appears to be fine now.
>
> -Paul
>
> On Tue, Jan 11, 2011 at 5:43 PM, Jason Clemons <[email protected]> wrote:
>
>> Hi,
>>
>> I have machine running 64Bit Ubuntu with 8GB or RAM.  When I run
>> simconfig
>> after starting qemu with 4096M for memory I get an address out of range
>> error during the simulation:
>>
>> ERROR: guest physical address 0x11fe9fd80 is out of bounds
>>
>>
>> The physical address changes but the error repeats over and over.  Where
>> can I set the maximum memory limit for the system under test?
>>
>>
>> Thanks,
>>
>> Jason Clemons
>>
>>
>> _______________________________________________
>> http://www.marss86.org
>> Marss86-Devel mailing list
>> [email protected]
>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110215/1ec17278/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-Fix-erroneous-error-print-when-running-with-3.5GB-of.patch
> Type: text/x-patch
> Size: 1553 bytes
> Desc: not available
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110215/1ec17278/attachment-0001.bin>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 15 Feb 2011 11:04:22 -0500
> From: Jason Clemons <[email protected]>
> To: DRAM Ninjas <[email protected]>
> Cc: marss86-devel <[email protected]>
> Subject: Re: [marss86-devel] Maximum QEMU/System memory size
> Message-ID: <[email protected]>
> Content-Type: text/plain;     charset=ISO-8859-1;     DelSp="Yes";
>       format="flowed"
>
> Paul,
>
>
> The patch works.  Thanks for looking into this.
>
>
> -jlclemon
>
> Quoting DRAM Ninjas <[email protected]>:
>
>> I'm sorry that I never got around to looking at this, but it turns out
>> the
>> error message was just meaningless. Essentially, if you ask for more
>> than
>> 3.5G of memory, QEMU leaves a hole between 3.5G and 4.0G and so some
>> extra
>> logic was required to determine if an address was actually out of
>> bounds.
>>
>> Anyways, I've written a tiny patch and tested with both 4GB and 8GB and
>> it
>> appears to be fine now.
>>
>> -Paul
>>
>> On Tue, Jan 11, 2011 at 5:43 PM, Jason Clemons <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> I have machine running 64Bit Ubuntu with 8GB or RAM.  When I run
>>> simconfig
>>> after starting qemu with 4096M for memory I get an address out of range
>>> error during the simulation:
>>>
>>> ERROR: guest physical address 0x11fe9fd80 is out of bounds
>>>
>>>
>>> The physical address changes but the error repeats over and over.
>>> Where
>>> can I set the maximum memory limit for the system under test?
>>>
>>>
>>> Thanks,
>>>
>>> Jason Clemons
>>>
>>>
>>> _______________________________________________
>>> http://www.marss86.org
>>> Marss86-Devel mailing list
>>> [email protected]
>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>>
>>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 Feb 2011 11:44:55 -0500
> From: DRAM Ninjas <[email protected]>
> To: marss86-devel <[email protected]>
> Subject: [marss86-devel] mesiBus: dataQueue never used?
> Message-ID:
>       <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I've been looking at the mesiBus code and trying to understand what's
> going
> on. One thing I noticed is that a BusControllerQueue has a dataQueue
> member
> -- which I presumed was for the response path on the bus. However, after
> looking around, it appears that the only place where dataQueue is used is
> when it is initialized in mesiBus.cpp:87, but then never referenced again.
>
> On the return path in data_broadcast_cb, there is this code:
>
> 450     if(!can_broadcast(pendingEntry->controllerQueue,
> pendingEntry->request)) {
> 451         memoryHierarchy_->add_event(&dataBroadcast_,
> 452                 BUS_BROADCASTS_DELAY, arg);
>
> But the pendingEntry's controllerQueue is copied in
> broadcast_completed_cb:
>
> 347         pendingEntry->controllerQueue = queueEntry->controllerQueue;
>
> Which happens to be the 'queue' and not 'dataQueue'.
>
> Anyways, this is a long-winded preamble to a simple question: are the
> response queues and the request queues meant to be the same? In other
> words,
> it looks like before completing a response, this code checks that the
> request queue (BusControllerQueue::queue) is free, and not the response
> queue (BusControllerQueue::dataQueue). Unless, of course, I'm misreading
> the
> code.
>
> Thanks,
> Paul
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110215/3d09574f/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> http://www.marss86.org
> Marss86-Devel mailing list
> [email protected]
> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>
>
> End of Marss86-Devel Digest, Vol 12, Issue 6
> ********************************************
>


_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel

Reply via email to