Hi Nilay,

My suggestion would be to limit the parallel event queues to either
different systems (like now), or to coarse-grained sub-systems. For the
latter, a possible first step would be to make the bus bridge a
synchronisation point. There is no shared state in the bridge besides the
pushing and popping of the queues (much like a mesochronous FIFO).

We will need some additional hygiene to pull this off though, as there
currently are devices connected to the membus residing in the ³I/O
subsystem². Perhaps a good first step is to add the notion of a subsystem
and clean-up the object hierarchy.

Andreas

On 26/11/2013 14:10, "Nilay Vaish" <[email protected]> wrote:

>Now that the multiple eventq patch is in the repo, it is time to discuss
>the steps that we should be taking next.  In past, I have tried making
>caches in ruby use the same eventq as the owner cpu.  Since a lot
>information in being recorded in a centralized fashion, it is difficult
>to
>get this right.  While some of this has changed since I modified the way
>statistics are collected in ruby,  this always gets me into thinking
>about
>how this might affect the performance of a single threaded simulation.
>
>What do other developers think we should be doing next?
>
>--
>Nilay
>_______________________________________________
>gem5-dev mailing list
>[email protected]
>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.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to