got it. I've changed it to your previous fix by using smaller chunks, which
also works fine : )
Thanks!
Jiayuan
----- Original Message -----
From: "Steve Reinhardt" <[EMAIL PROTECTED]>
To: "M5 users mailing list" <[email protected]>
Sent: 2007年12月3日 8:02 AM
Subject: Re: [m5-users] panic on partially satisfying the functional request
> The danger with this fix is that you might not get exactly the right
> answer... e.g., in the situation that appears to be happening to you,
> the functional read will get the cache block contents out of memory
> *without* the effect of the pending store that caused the problem in
> the first place. This may not matter (since it's just printing
> output) but if you start to see situations where there are small
> corruptions in the results of syscalls (especially write()) then this
> is very likely what's happening.
>
> Steve
>
> On Dec 1, 2007 3:39 PM, Jiayuan Meng <[EMAIL PROTECTED]> wrote:
>> 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
>>
> _______________________________________________
> 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
