it works! if what you meant is just returning false when came to this panic in
Packet::checkFunctional(Addr addr, int size, uint8_t *data);
I tried with the following in mem/packet.cc ln 186:
--- panic("Memory value only partially satisfies the functional request.
Now what?");
+++ return false;
I'm happy with the solution :) Thanks a lot!
Jiayuan
----- Original Message -----
From: "Steve Reinhardt" <[EMAIL PROTECTED]>
To: "M5 users mailing list" <[email protected]>
Sent: 2007年12月3日 5:21 AM
Subject: Re: [m5-users] panic on partially satisfying the functional request
>I was thinking that if checkFunctional() only partially satisfies the
> request, then it would just return false as if it hadn't satisfied it
> at all, and the rest of the code would continue searching for a match
> as it does currently (including searching through the rest of the
> MSHRs, the actual cache, buffered writebacks, etc.). Then the only
> changes would be internal to checkFunctional(), where a later match
> between two packets would have to make sure it doesn't clobber the
> part that's already partially satisfied.
>
> Steve
>
> On Dec 2, 2007 1:01 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>> You could correctly satisfy a read if you could get the rest of the
>> block. The only problem I see with having the cache issues a
>> functional read further down in the hierarchy to get the rest of the
>> block when this case happens is: what if the block in question is
>> somewhere else in the cache (maybe the block is being evicted and is
>> currently waiting to be transmitted out of the cache)? The functional
>> access is going to go down to the next level, so it will never been
>> seen.
>>
>> Right now we have the simple case of you call checkFunctional() on two
>> packets and it "does the right thing," and then tells the calling
>> function to either continue sending functional access through the
>> memory hierarchy or not (or panics). To make something like this work
>> there would need to be a closer coupling between checkFunctional() and
>> the code calling checkFunctional() so there would be some interface to
>> other places packets could be hiding in each memory object before
>> continuing on to the next level.
>>
>> Ali
>>
>>
>>
>> On Dec 2, 2007, at 3:48 PM, Steve Reinhardt wrote:
>>
>> > Yea, that looks like exactly what's happening here: the CPU has issued
>> > a store (8 bytes) that missed in the cache, and then went and did a
>> > write() on the buffer it just wrote to, and the functional read that's
>> > getting the buffer contents for the write() is running into the
>> > buffered store in the MSHR.
>> >
>> > One fix would be to break the functional read into smaller chunks...
>> > 8-byte chunks would solve this particular problem, but in reality
>> > there's no reason it couldn't be a byte store, so you'd need to do
>> > 1-byte reads to really fix the problem. Unfortunately that could be
>> > really slow for large accesses, but maybe it doesn't happen often
>> > enough to matter.
>> >
>> > I also think the valid-bit-per-byte thing could work; I'm not sure
>> > what you mean by "no way to check the next place in the cache"... as
>> > long as checkFunctional() doesn't signal that it's completed the
>> > request, the system will keep searching for additional places to find
>> > the data.
>> >
>> > Steve
>> >
>> > On Dec 2, 2007 12:00 AM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>> >> There can still be a problem if there is an outstanding write to the
>> >> block you're reading from because the request will see the new
>> >> updated
>> >> write data, but the cache doesn't have the rest of the block yet so
>> >> it
>> >> can't be satisfied. The only easy solution is to write in smaller
>> >> chunks. A more difficult solution is to have a valid bit for each
>> >> byte
>> >> of the packet or maybe some kind of nested functional access, where
>> >> the functional access would try to continue down the hierarchy
>> >> looking
>> >> for the fullest chunk of data and recombined itself on the way up.
>> >> Trouble is most memory devices would have a problem with this because
>> >> there is no way to check the next place in the cache for example.
>> >> Ali
>> >>
> _______________________________________________
> 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
