Re: [Gems-users] CPU accesses to L2 cache

[Dan Gibson <degibson@xxxxxxxx>]

cpu-switch-time should only (greatly) affect the number of L2 accesses for very short simulations.

As I recall, your original question was something about cpu0 issuing more L2 accesses than other processors -- under what workload (if not ps/prstat) were you observing cpu0? And for how many Simics cycles? DNUCA protocol again?

In reference to your longer run, which protocol and workload?

Regards,
Dan

Daniele Bordes wrote:

Thank you for your quick and exhaustive reply, Dan. I try to answer
your last questions:

  

dump-stats reports the stats for the entire execution history.
    

I load Ruby modules after executing prstat and ps commands, so I think
no commands are in execution when I load Ruby.

  

How about cpu-switch-time 1?
    

At the moment I cannot verify and I don't remember, but I think I left
it as default. In Simics guide I read that setting that value low
would slow simulations very much. Do you think that value could affect
CPU0's number of accesses?

  

Did you run the benchmark for long time? Did you start ruby after the
processor_bind() calls to avoid the single-cpu startup transient?
    

Yes. I run benchmarks till completion (it takes me nearly two days)
and I load and start ruby after processor_bind calls. That is, threads
binding to CPUs happens before the loading of ruby.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.