Hm, I'm not too worried about it at this point. I've hacked together a
ridiculous bus model that's meant to eliminate the bus as the bottleneck, so
at this point I've just made queue huge and I'm not seeing any contention on
it.

I guess just something to keep in mind when you guys are doing code
cleanups.

-Paul

On Wed, Feb 16, 2011 at 12:23 PM, avadh patel <[email protected]> wrote:

> Yes. You are right about 'dataQueue' not being used at all. I think I
> missed it totally when I code that.
> If you are interested to utilize this queue for better performance then we
> can change the response path to use dataQueue and free up some space on
> request queue.
>
> - Avadh
>
> On Tue, Feb 15, 2011 at 9:44 AM, DRAM Ninjas <[email protected]> wrote:
>
>> I've been looking at the mesiBus code and trying to understand what's
>> going on. One thing I noticed is that a BusControllerQueue has a dataQueue
>> member -- which I presumed was for the response path on the bus. However,
>> after looking around, it appears that the only place where dataQueue is used
>> is when it is initialized in mesiBus.cpp:87, but then never referenced
>> again.
>>
>> On the return path in data_broadcast_cb, there is this code:
>>
>> 450     if(!can_broadcast(pendingEntry->controllerQueue,
>> pendingEntry->request)) {
>> 451         memoryHierarchy_->add_event(&dataBroadcast_,
>> 452                 BUS_BROADCASTS_DELAY, arg);
>>
>> But the pendingEntry's controllerQueue is copied in
>> broadcast_completed_cb:
>>
>> 347         pendingEntry->controllerQueue = queueEntry->controllerQueue;
>>
>> Which happens to be the 'queue' and not 'dataQueue'.
>>
>> Anyways, this is a long-winded preamble to a simple question: are the
>> response queues and the request queues meant to be the same? In other words,
>> it looks like before completing a response, this code checks that the
>> request queue (BusControllerQueue::queue) is free, and not the response
>> queue (BusControllerQueue::dataQueue). Unless, of course, I'm misreading the
>> code.
>>
>> Thanks,
>> Paul
>>
>>
>>
>>
>>
>> _______________________________________________
>> http://www.marss86.org
>> Marss86-Devel mailing list
>> [email protected]
>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
>>
>>
>
_______________________________________________
http://www.marss86.org
Marss86-Devel mailing list
[email protected]
https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel

Reply via email to