Hello Clint, you were right there are a bunch of issues, I successfully reorder the accesses, but in some moments there are some problems. What I do now is reorder the slots in the biu, putting the slot that I want after the one executed previously, I am using FCFS. My reordering code is right after the call to fill_biu_slot in dramsim.cc. But sometimes DRAMsim does not follow the same order. Let me explain this with an example, here I am giving priority to the accesses from the core 2. List: 4 3 2 1 0 0 0 Reorder: 2 4 3 1 0 0 0 --Execution 2 (sid = 0) List: 0 4 3 1 0 0 0 New Petition (2): 2 4 3 1 0 0 0 Reorder: 4 2 3 1 0 0 0 --Execution 2 (sid = 1) List: 4 0 3 1 0 0 0 New Petition (2): 4 2 3 1 0 0 0 Reorder: 4 3 2 1 0 0 0 0 --Execution 2 (sid = 2) Until now everything perfect, but sometimes DRAMSim does not keep the order, incrementing sid all the time, this is what happen sometimes: List: 4 3 2 1 0 0 0 --Execution 4 (sid = 0) This happen because in the function "find_critical_word_ready_slot" returns a sid = 0 because in the first slot in the biu (petition 4) the critical_word_ready has changed to 1. What I do not understand is why is changing in that moment to 1, and not before. I believe that the origin of this problems is because I am not reordering the biu before the commands go to the transaction queue. I do not consider this problem so complex, I just need to reorder the biu and DRAMSim should take the commands keeping the same sid order. Any ideas of what is going wrong and why DRAMSim does not keep the same sid order?. Thanks so much for the help.
From: [email protected]: [email protected]: Wed, 28 Jan 2009 14:06:15 -0500Subject: Re: [m5-users] [PATCH] Beta patch for M5 2.0 DRAMsim implemention 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]: [email protected]: Tue, 27 Jan 2009 13:36:31 -0500Subject: 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 [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 [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/m5-users _________________________________________________________________ Anímate y disfruta con los mejores juegos de Messenger, ¡descúbrelos! http://www.vivelive.com/juegos/
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
