We would need partial valid bits for that making the packet bigger,
but yea that would work.
Ali
On Dec 2, 2007, at 4:21 PM, Steve Reinhardt wrote:
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
