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" <m5-users@m5sim.org>
> 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
> > m5-users@m5sim.org
> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
> >
> _______________________________________________
> m5-users mailing list
> m5-users@m5sim.org
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
