Hi Daecheol,
The complication comes from handling all of the corner cases. What happens
if you get a flush for a line when you've sent a request but haven't
received a response? What about when you've received an invalidation, but
you haven't responded yet? There are many intermediate states that you have
to reason about what the right action is in each case on a flush. It's not
*hard* it just isn't trivial.
Ignoring the flushes at the CPU may be OK. It depends on if they are
functionally required or not.
Cheers,
Jason
On Tue, Oct 6, 2020 at 1:14 AM Daecheol You wrote:
> Thanks Jason,
>
> I just thought that FLUSH request can be handled with invalidate and
> write-back. Could you let me know what other things should be considered
> for FLUSH? Or is it fine modifying the CPU sequencer that it just ignore
> the FLUSH request?
>
> 2020년 10월 6일 (화) 오전 8:15, Jason Lowe-Power 님이 작성:
>
>> Hi Daecheol,
>>
>> Unfortunately, the flush command is a bit more complicated to implement
>> than just a simple replacement. I responded to another message about this
>> on the mailing list a few minutes ago that you can see for more information.
>>
>> Cheers,
>> Jason
>>
>> On Mon, Sep 28, 2020 at 8:59 PM Daecheol You via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hi all,
>>>
>>> I am running PARSEC benchmark with full system simulation.
>>> The CPU model is O3CPU (parameters tuned) with ARM ISA and
>>> MESI_Three_Level protocol were used. (build/ARM_MESI_Three_Level/gem5.opt)
>>> While the benchmark is running, panic occurs since the L0 cache controller
>>> gets unsupported type of request with the following message.
>>>
>>> panic: Runtime Error at MESI_Three_Level-L0cache.sm:287: Invalid
>>> RubyRequestType.
>>>
>>> I checked the type of request which triggers panic by inserting debug
>>> message at mandatory_request_type_to_event() in
>>> MESI_Three_Level-L0cache.sm. It was FLUSH request, and it is not handled
>>> properly by the protocol. It seems that other protocols also do not handle
>>> FLUSH request. I wonder why the protocol does not process FLUSH request
>>> from a mandatory queue, and how I workaround this issue.
>>>
>>> I modified the MESI_Three_Level-L0cache.sm so that it triggers
>>> L0_Replacement event and pop the mandatory queue explicitly for the FLUSH
>>> request. However, panic occurs at wakeup() function of sequencer
>>> (src/mem/ruby/system/Sequencer.cc) since the FLUSH request is not erased
>>> from the m_RequestTable. (Unlike read/writeCallback, evictionCallback does
>>> not erase the entry in request table.)
>>> It would be very helpful if you guys provide me a guide for this issue.
>>>
>>> Thanks,
>>>
>>> Daecheol.
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
