mem: Split WriteInvalidateReq into write and invalidate

Information
Submitter:	Andreas Hansson
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 10886:ecf9571145d8
---------------------------
mem: Split WriteInvalidateReq into write and invalidate

WriteInvalidateReq ensures that a whole-line write does not incur the
cost of first doing a read exclusive, only to later overwrite the
data. This patch splits the existing WriteInvalidateReq into a
WriteLineReq, which is done locally, and an InvalidateReq that is sent
out throughout the memory system. The WriteLineReq re-uses the normal
WriteResp.

The change allows us to better express the difference between the
cache that is performing the write, and the ones that are merely
invalidating. As a consequence, we no longer have to rely on the
isTopLevel flag. Moreover, the actual memory in the system does not
see the intitial write, only the writeback. We were marking the
written line as dirty already, so there is really no need to also push
the write all the way to the memory.

The overall flow of the write-invalidate operation remains the same,
i.e. the operation is only carried out once the response for the
invalidate comes back. This patch adds the InvalidateResp for this
very reason.

Testing Done

Issue Summary

Description	From	Last Updated	Status
Why is this true? Suppose we have two cores with private caches and both of them have some block in ...	Nilay Vaish	July 2, 2015, 6:53 a.m.	Dropped
I think this comment is not right since write invalidate request no longer exists.	Nilay Vaish	July 2, 2015, 6:53 a.m.	Dropped

Description:

~		Changeset 10876:3177f19d7897
	~	Changeset 10876:f265658dbcaa

		mem: Split WriteInvalidateReq into write and invalidate

		This patch splits the existing WriteInvalidateReq into a WriteLineReq,
		which is done locally, and an InvalidateReq that is sent out
		throughout the memory system. The WriteLineReq re-uses the normal
		WriteResp.

		The change allows us to better express the difference between the
		cache that is performing the write, and the ones that are merely
		invalidating. As a consequence, we no longer have to rely on the
		isTopLevel flag. Moreover, the actual memory in the system does not
		see the intitial write, only the writeback. We were marking the
		written line as dirty already, so there is really no need to also push
		the write all the way to the memory.

		The overall flow of the write-invalidate operation remains the same,
		i.e. the operation is only carried out once the response for the
		invalidate comes back. This patch adds the InvalidateResp for this
		very reason.

Diff:

Revision 2 (+61 -45)

Show changes

	src/mem/packet.hh
	src/mem/packet.cc
	src/mem/cache/cache_impl.hh
	src/mem/ruby/system/RubyPort.cc

Before I read this patch, I would like you to specifically state in the
patch comment what the purpose of the original command was.

Andreas Hansson June 29, 2015, 2:39 a.m. (June 29, 2015, 2:39 a.m.)

Sure. I've added a sentence. If you need more info than that I'd suggest to check the changeset that added the support.

Description:

~		Changeset 10876:f265658dbcaa
	~	Changeset 10886:66fdc1c6f94f

		mem: Split WriteInvalidateReq into write and invalidate

~		This patch splits the existing WriteInvalidateReq into a WriteLineReq,
~		which is done locally, and an InvalidateReq that is sent out
~		throughout the memory system. The WriteLineReq re-uses the normal
	~	WriteInvalidateReq ensures that a whole-line write does not incur the
	~	cost of first doing a read exclusive, only to later overwrite the
	~	data. This patch splits the existing WriteInvalidateReq into a
	+	WriteLineReq, which is done locally, and an InvalidateReq that is sent
	+	out throughout the memory system. The WriteLineReq re-uses the normal
		WriteResp.

		The change allows us to better express the difference between the
		cache that is performing the write, and the ones that are merely
		invalidating. As a consequence, we no longer have to rely on the
		isTopLevel flag. Moreover, the actual memory in the system does not
		see the intitial write, only the writeback. We were marking the
		written line as dirty already, so there is really no need to also push
		the write all the way to the memory.

		The overall flow of the write-invalidate operation remains the same,
		i.e. the operation is only carried out once the response for the
		invalidate comes back. This patch adds the InvalidateResp for this
		very reason.

Diff:

Revision 3 (+61 -45)

Show changes

	src/mem/packet.hh
	src/mem/packet.cc
	src/mem/cache/cache_impl.hh
	src/mem/ruby/system/RubyPort.cc

Ship It!

Suppose two cores issue whole line writes. The two caches attached to the cores would issue
invalidates. Where are these invalidates ordered?

src/mem/cache/cache_impl.hh (Diff revision 3)

Why is this true?  Suppose we have two cores with private caches and both of them have some block in shared state and then one of them writes to this entire block.  Would not this assert fail when invalidate is received by the private cache of the other core?
Though it might be that classic's coherence protocol behaves in completely different fashion.

Show all issues

Andreas Hansson July 2, 2015, 6:53 a.m. (July 2, 2015, 6:53 a.m.)

They need the line in writeable state to write to it. The protocol ensures that this is the case. If you try and write in shared state, the actual write only happens when the response comes back with a "not shared" flag.

Andreas Hansson July 2, 2015, 7:05 a.m. (July 2, 2015, 7:05 a.m.)

The InvalideResp that is. In the classic memory system the MSHR is always the ordering point, and once we have this response everyone else now has to adhere to it as well.

src/mem/cache/cache_impl.hh (Diff revision 3)

I think this comment is not right since write invalidate request no longer exists.

Show all issues

Andreas Hansson July 2, 2015, 6:53 a.m. (July 2, 2015, 6:53 a.m.)
```
I'll update it before comitting.
```

Description:

~		Changeset 10886:66fdc1c6f94f
	~	Changeset 10886:ecf9571145d8

		mem: Split WriteInvalidateReq into write and invalidate

		WriteInvalidateReq ensures that a whole-line write does not incur the
		cost of first doing a read exclusive, only to later overwrite the
		data. This patch splits the existing WriteInvalidateReq into a
		WriteLineReq, which is done locally, and an InvalidateReq that is sent
		out throughout the memory system. The WriteLineReq re-uses the normal
		WriteResp.

		The change allows us to better express the difference between the
		cache that is performing the write, and the ones that are merely
		invalidating. As a consequence, we no longer have to rely on the
		isTopLevel flag. Moreover, the actual memory in the system does not
		see the intitial write, only the writeback. We were marking the
		written line as dirty already, so there is really no need to also push
		the write all the way to the memory.

		The overall flow of the write-invalidate operation remains the same,
		i.e. the operation is only carried out once the response for the
		invalidate comes back. This patch adds the InvalidateResp for this
		very reason.

Diff:

Revision 4 (+64 -48)

Show changes

	src/mem/packet.hh
	src/mem/packet.cc
	src/mem/cache/cache_impl.hh
	src/mem/ruby/system/RubyPort.cc

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Description:

Changeset 10876:3177f19d7897

Changeset 10876:f265658dbcaa

Diff:

Description:

Changeset 10876:f265658dbcaa

Changeset 10886:66fdc1c6f94f

Diff:

Description:

Changeset 10886:66fdc1c6f94f

Changeset 10886:ecf9571145d8

Diff:

Status: Closed (submitted)