Re: [gem5-dev] storing stats in a database?

2017-09-15 Thread Jason Lowe-Power 
Hi Gabe,

There's currently no functionality for that. However, I believe there have
been some efforts in the past to get something like this to work, though
none of them were committed.

I've heard that there may be some people working on better stats support.
So, if you're thinking about improving the stats I would make sure that
there aren't duplicate efforts :). Personally, I would *love* to see
something like database support. Pandas (http://pandas.pydata.org/) would
be even cooler, IMO.

Cheers,
Jason

On Fri, Sep 15, 2017 at 3:42 PM Gabe Black  wrote:

> Hi folks. This may be documented somewhere already, but is there a way to
> collect stats to a database rather than to a text file? That would be
> helpful when collecting stats periodically to get a graph over time, which
> tends to produce a lot of output that needs to be processed before it's
> useful.
>
> Gabe
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] storing stats in a database?

2017-09-15 Thread Gabe Black 
Hi folks. This may be documented somewhere already, but is there a way to
collect stats to a database rather than to a text file? That would be
helpful when collecting stats periodically to get a graph over time, which
tends to produce a lot of output that needs to be processed before it's
useful.

Gabe
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Packet ID messages in the protobuf packet trace format

2017-09-15 Thread Gabe Black 
I wouldn't mind adding an explicit master ID field to the packet, but
that's not actually what I'm asking about. I'm suggesting adding a whole
new message type (like the header messages vs the request messages) which
describes what a particular ID represents. Obviously we don't want to send
something like system.cpu0.itlb with every access, but that's way more
useful than just the number 2, for instance. I'd like to embed a mapping
between those in the trace rather than having to dump the table through
some other means and to keep that alongside the trace for later translation.

Gabe

On Fri, Sep 15, 2017 at 1:49 AM, Andreas Hansson 
wrote:

> Hi Gabe,
>
> The pkt_id field was intentionally left up to the user to populate as they
> see fit. Master ID, stream ID, or PC as in the case of the mem_probe used
> by the CommMonitor. If you think there is need for another ID, then by all
> means we should add it. The question is, could you use the ID that is
> already there?
>
> If we change the format I agree we should make the field optional to not
> deprecate old traces.
>
> Andreas
>
> On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black"
>  wrote:
>
> >Hi folks. I'd like to propose adding a new type of message to the
> >packet.proto format used for protobuf memory traces.
> >
> >Currently, packet IDs are opaque numbers which in some hand wavy way
> >"identify" a packet, presumably to say where that packet came from
> >(instruction, bus master, etc.) Currently there is no in-channel way to
> >map
> >those numbers to something more useful like an object name. What are
> >people's thoughs as far as adding a new message type which would provide
> >that information? Off the top of my head, it would make sense to have a
> >single message per ID, and to have a single "string" type field which
> >would
> >be used to describe the meaning of the ID in whatever way was appropriate.
> >
> >I haven't thought through the specifics very much, so suggestions would be
> >very appreciated. Currently I've got a hacky side-channel way to preserve
> >that information, but it would be less fragile and inconvenient if that
> >was
> >preserved directly in the trace itself.
> >
> >Also, would this warrant a new file format version number, or would the
> >fact that the additional messages can be ignored with no ill effect let us
> >keep it at the same number?
> >
> >Gabe
> >___
> >gem5-dev mailing list
> >gem5-dev@gem5.org
> >http://m5sim.org/mailman/listinfo/gem5-dev
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Packet ID messages in the protobuf packet trace format

2017-09-15 Thread Andreas Hansson 
Hi Gabe,

The pkt_id field was intentionally left up to the user to populate as they
see fit. Master ID, stream ID, or PC as in the case of the mem_probe used
by the CommMonitor. If you think there is need for another ID, then by all
means we should add it. The question is, could you use the ID that is
already there?

If we change the format I agree we should make the field optional to not
deprecate old traces.

Andreas

On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black"
 wrote:

>Hi folks. I'd like to propose adding a new type of message to the
>packet.proto format used for protobuf memory traces.
>
>Currently, packet IDs are opaque numbers which in some hand wavy way
>"identify" a packet, presumably to say where that packet came from
>(instruction, bus master, etc.) Currently there is no in-channel way to
>map
>those numbers to something more useful like an object name. What are
>people's thoughs as far as adding a new message type which would provide
>that information? Off the top of my head, it would make sense to have a
>single message per ID, and to have a single "string" type field which
>would
>be used to describe the meaning of the ID in whatever way was appropriate.
>
>I haven't thought through the specifics very much, so suggestions would be
>very appreciated. Currently I've got a hacky side-channel way to preserve
>that information, but it would be less fragile and inconvenient if that
>was
>preserved directly in the trace itself.
>
>Also, would this warrant a new file format version number, or would the
>fact that the additional messages can be ignored with no ill effect let us
>keep it at the same number?
>
>Gabe
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

2017-09-15 Thread Cron Daemon 
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/minor-timing: FAILED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/o3-timing: FAILED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-atomic: FAILED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-timing: FAILED!
* build/RISCV/tests/opt/quick/se/00.hello/riscv/linux/simple-timing-ruby: 
FAILED!*** gem5: ERROR: gem5 exited with non-zero status: 1
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/minor-timing: 
FAILED!*** diff[simout]: SKIPPED
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing: 
FAILED!*** gem5 stderr ***
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64a/simple-timing-ruby:
 FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/minor-timing: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby:
 FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/simple-atomic: 
FAILED!*** gem5 stderr ***
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/minor-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/simple-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64d/simple-timing-ruby:
 FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/minor-timing: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64f/simple-timing-ruby:
 FAILED!*** diff[config.ini]: SKIPPED
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/minor-timing: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64i/simple-timing-ruby:
 FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/minor-timing: 
FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/o3-timing: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-atomic: 
FAILED!
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-timing: 
FAILED!--- quick/se/02.insttest/riscv/linux-rv64m/simple-timing-ruby ---
* 
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64m/simple-timing-ruby:
 FAILED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: CHANGED!
* build/ARM/tests/opt/quick/se/00.hello/arm/linux/minor-timing: CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing: 
CHANGED!
* 
build/ARM/tests/opt/quick/fs/10.linux-boot/arm/linux/realview-simple-timing-dual:
 CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: passed.
 * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: