Changing the BIU ordering would change the order in which they are
converted into transactions. The policy itself affects the
transactions, so if you were able to reorder the entries in the BIU
before it reached the transaction scheduler, you could make an FCFS
system to whatever you wanted it to. The only issue, is that the
policy applies not only to memory requests, but the commands that each
request is made up of. The get_next_cmd_to_issue does the analog of
get_next_request_from_biu for commands.
By reordering the BIU and using the FCFS policy, what should happen is
that the earlier requests will always have their commands executed
before any other, though commands from multiple requests may still be
executed in parallel when they do not conflict. If you actually
changed the policy to enforce that all commands from an earlier
request would go ahead of all others, then you would reduce the memory
system performance in a very unrealistic way. However, reordering the
BIU entries (as long as you pay attention to read and write ordering
constraints) should not have any adverse effects on overall system
performance.
I'm not sure what you mean by hits and misses, as a centralized main
memory always has 100% hit rate (since it is neither a cache nor a
memory slice).
- Clint
On Jan 28, 2009, at 1:39 PM, Angela Carlsson wrote:
Hello Clint, thanks for your answer and for your advice of using the
priority as a way to identify the cores, it is a good idea.
I hope you can help me. I have been looking through the code about
the policies trying to do what I am looking for, but the code is a
little complex. Do you know if FCFS serves the first command that
finds in the biu?. The reason to ask this, is that reordering the
biu according to my policy is very simple, I am thinking that if I
can reorder the biu and if FCFS take the first command, in this way
is easy to do what I am trying to do. I just put in the first
position of the biu an access of core x, and that's all.
Regarding the statistics, is there any stat related with the hits
and the misses?, I am printing the stats, with mem_print_stat(...)
but I do not see any parameter to print the hits and miss in the
memory. Do you know any parameter to print that information?. Thank
you.
Thanks a lot for your help, it is really appreciable.
From: [email protected]
To: [email protected]
Date: Tue, 27 Jan 2009 13:36:31 -0500
Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
implemention
Ah, I see what you are saying, but that functionality actually
resides within DRAMsim itself. The doTiming method of the DRAMsim M5
object can take as many packets as the network can give it, but it
simply finds a free slot in the BIU and places it there for DRAMsim
to process on the next memory controller cycle. On line 240, you
will see the priority variable which is constantly set to zero.
According to the DRAMsim code, that is intended for a purpose such
as you are looking for, but I don't believe it does the correct
thing right now. If you have the priority field set based on the
core number, and then you modify/create a policy to do as you want
within DRAMsim, you should be able to get the desired behavior.
The biggest issue you may face is the fact that to actually make the
system work, you would have to have requests arrive at (nearly) the
same time. If the memory controller is connected to a bus, this is
not possible, which would skew the results. If the pressure on the
memory system is high enough, then it would be possible to see the
selection policy in action, but it is more difficult to guarantee.
Hopefully this information helps.
- Clint
On Jan 27, 2009, at 11:52 AM, Angela Carlsson wrote:
Hello Clint thanks a lot for the patch. I have been testing it and
it seems that works fine. Thanks a lot.
I have a question regarding the reordering of the accesses. Do the
selection policies Greedy, FCFS... work?. What I mean is that when
there are several accesses at the *same* time all the accesses are
stored inside of the transaction queue in DRAMSim? or on the
contrary the accesses are sent one by one to DRAMSim (then DRAMSim
process the petition and send the answer, in this case DRAMSim works
as FCFS). In this last case then they are stored in the retry list
in the bus.cc file. My interest for this is to give some priorities
for accesses from some cores, that's why I am asking this, because I
want to know who stores the petition, to reorder them there.
I hope you knwo what I mean if not please let me know. Thanks a lot
in advance.
> Date: Fri, 23 Jan 2009 12:41:10 -0500
> From: [email protected]
> To: [email protected]
> Subject: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim
implemention
>
> # HG changeset patch
> # User Clint Smullen <[email protected]>
> # Date 1232732406 18000
> # Node ID a95dd3a28ecb82a074de030367fe641d52aaf148
> # Parent 0397aa216e2290a50fb7138bd28563926573c929
> Beta patch for M5 2.0 DRAMsim implemention.
Con el nuevo Windows Live lo tendrás todo al alcance de tu mano
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
Actualízate, descubre el nuevo Windows Live Messenger. ¡Descárgatelo
ya! _______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
