CSC/ECE 506 Spring 2010/8a sk - Revision history

Laddaga: /* Implementation Complexities */

2012-03-29T03:13:45Z

Implementation Complexities

← Older revision		Revision as of 03:13, 29 March 2012
Line 95:		Line 95:

	==Implementation Complexities ==		==Implementation Complexities ==
	In comparision with the MESI protocol, the addition of 'Forward' state in the MESIF protocol reduces the complexity due to a reduction in the communication between cores. This reduced communication is due to the design of specific state such that a single cache will respond to all the read requests for shared data. The implementation of write-backs necessitates a 'write-buffer' like in case of ~~the~~ MESI protocol, and the bus transactions relevant to these buffered blocks require careful handling. Though the inclusion of an additional state does increase design complexity, the working of this additional state and the concomitant decrease in communication between cores leads to the ~~implemnatation~~ complexity being similar to that in the MESI protocol.		In comparision with the MESI protocol, the addition of 'Forward' state in the MESIF protocol reduces the complexity due to a reduction in the extent of communication between cores. This reduced communication is due to the design of specific state such that a single cache will respond to all the read requests for shared data. The implementation of write-backs necessitates a 'write-buffer' like in the case of MESI protocol, and the bus transactions relevant to these buffered blocks require careful handling. Though the inclusion of an additional state does increase design complexity, the working of this additional state and the concomitant decrease in communication between cores leads to the overall implementation complexity being similar to that in the MESI protocol.
	<br>		<br>

Laddaga: /* Implementation Complexities */

2012-03-29T03:05:23Z

Implementation Complexities

← Older revision		Revision as of 03:05, 29 March 2012
Line 95:		Line 95:

	==Implementation Complexities ==		==Implementation Complexities ==
	In comparision with the MESI protocol, the addition of 'Forward' state in the MESIF protocol reduces the complexity due to a reduction in the communication between cores. This reduced communication is due to the design of specific state such that a single cache will respond to all the read requests for shared data. Though the inclusion of an additional state does increase design complexity, the working of this additional state and the concomitant decrease in communication between cores leads to the complexity being similar to that in the MESI protocol.		In comparision with the MESI protocol, the addition of 'Forward' state in the MESIF protocol reduces the complexity due to a reduction in the communication between cores. This reduced communication is due to the design of specific state such that a single cache will respond to all the read requests for shared data. The implementation of write-backs necessitates a 'write-buffer' like in case of the MESI protocol, and the bus transactions relevant to these buffered blocks require careful handling. Though the inclusion of an additional state does increase design complexity, the working of this additional state and the concomitant decrease in communication between cores leads to the implemnatation complexity being similar to that in the MESI protocol.
	<br>		<br>

Laddaga: /* MESIF Protocol */

2012-03-29T03:01:27Z

MESIF Protocol

← Older revision		Revision as of 03:01, 29 March 2012
Line 93:		Line 93:
	[[File:MESIF cache state.jpg ]]		[[File:MESIF cache state.jpg ]]
	<br>		<br>

			==Implementation Complexities ==
			In comparision with the MESI protocol, the addition of 'Forward' state in the MESIF protocol reduces the complexity due to a reduction in the communication between cores. This reduced communication is due to the design of specific state such that a single cache will respond to all the read requests for shared data. Though the inclusion of an additional state does increase design complexity, the working of this additional state and the concomitant decrease in communication between cores leads to the complexity being similar to that in the MESI protocol.
			<br>

	== MESIF in Intel Nehalem Computer==		== MESIF in Intel Nehalem Computer==
	[http://rolfed.com/nehalem/nehalemPaper.pdf Intel Nehalem Computer] uses the MESIF protocol. In the Nehalem architecture each core has its own L1 and L2 cache. Nehalem does has a shared cache, implemented as L3 cache. This cache is shared among all cores and is relatively large. This cache is inclusive, meaning that		[http://rolfed.com/nehalem/nehalemPaper.pdf Intel Nehalem Computer] uses the MESIF protocol. In the Nehalem architecture each core has its own L1 and L2 cache. Nehalem does has a shared cache, implemented as L3 cache. This cache is shared among all cores and is relatively large. This cache is inclusive, meaning that

Skanaka: /* MESI Protocol */

2012-03-22T02:14:01Z

MESI Protocol

← Older revision		Revision as of 02:14, 22 March 2012
Line 55:		Line 55:
	*'''FlushOpt''': snooped request that indicates that an entire cache block is posted on the bus in order to supply it to another processor. We distinguish FlushOpt from Flush because while Flush is needed for write propagation, FlushOpt is not required for correctness. It is implemented as a performance enhancing feature that can be removed without impacting correctness. It is referred to as an optional block flush cache-to-cache transfer.		*'''FlushOpt''': snooped request that indicates that an entire cache block is posted on the bus in order to supply it to another processor. We distinguish FlushOpt from Flush because while Flush is needed for write propagation, FlushOpt is not required for correctness. It is implemented as a performance enhancing feature that can be removed without impacting correctness. It is referred to as an optional block flush cache-to-cache transfer.
	<br>		<br>
	MESI states under different conditions is shown in the figure below:br>		MESI states under different conditions is shown in the figure below:<br>
	[[File:MESI-state.jpg\|550px]]		[[File:MESI-state.jpg\|550px]]
	<br>		<br>

Laddaga: /* MESIF in Intel Nehalem Computer */

2012-03-22T01:57:36Z

MESIF in Intel Nehalem Computer

← Older revision		Revision as of 01:57, 22 March 2012
Line 96:		Line 96:
	[http://rolfed.com/nehalem/nehalemPaper.pdf Intel Nehalem Computer] uses the MESIF protocol. In the Nehalem architecture each core has its own L1 and L2 cache. Nehalem does has a shared cache, implemented as L3 cache. This cache is shared among all cores and is relatively large. This cache is inclusive, meaning that		[http://rolfed.com/nehalem/nehalemPaper.pdf Intel Nehalem Computer] uses the MESIF protocol. In the Nehalem architecture each core has its own L1 and L2 cache. Nehalem does has a shared cache, implemented as L3 cache. This cache is shared among all cores and is relatively large. This cache is inclusive, meaning that
	it duplicates all data stored in each indivitual L1 and L2 cache. This duplication greatly adds to the inter-core communication efficiency because any given core does not have to locate data in another processor’s cache. If the requested data is not found in any level of the core’s cache, it knows the data is also not present in any other core’s cache. To ensure coherency across all caches, the L3 cache has		it duplicates all data stored in each indivitual L1 and L2 cache. This duplication greatly adds to the inter-core communication efficiency because any given core does not have to locate data in another processor’s cache. If the requested data is not found in any level of the core’s cache, it knows the data is also not present in any other core’s cache. To ensure coherency across all caches, the L3 cache has
	additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>		additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Comparing Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>
	<br><br>		<br><br>
	The cache organization of a 8-core Intel Nehalem Processor is shown below:<br>		The cache organization of a 8-core Intel Nehalem Processor is shown below:<br>

Laddaga: /* MESIF in Intel Nehalem Computer */

2012-03-22T01:57:02Z

MESIF in Intel Nehalem Computer

← Older revision		Revision as of 01:57, 22 March 2012
Line 98:		Line 98:
	additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>		additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>
	<br><br>		<br><br>
	The cache organization of a 8-core Intel Nehalem Processor is shown below:<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Comparing Cache Architectures and Coherency Protocols on x86-64 Multicore SMP Systems]</ref><br>		The cache organization of a 8-core Intel Nehalem Processor is shown below:<br>
	[[File:Nehalem.jpg]]		[[File:Nehalem.jpg]]

Laddaga: /* MESIF in Intel Nehalem Computer */

2012-03-22T01:55:37Z

MESIF in Intel Nehalem Computer

← Older revision		Revision as of 01:55, 22 March 2012
Line 98:		Line 98:
	additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>		additional flags that keep track of which core the data came from. If the data is modified in L3 cache, then the L3 cache knows if the data came from a different core than last time,and that the data in the first core needs its L1/L2 values updated with the new data. This greatly reduces the amount of traditional “snooping” coherency traffic between cores.<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Cache Organization and Memory Management of the Intel Nehalem Computer Architecture]</ref>
	<br><br>		<br><br>
	The cache organization of a 8-core Intel Nehalem Processor is shown below:<br>		The cache organization of a 8-core Intel Nehalem Processor is shown below:<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Comparing Cache Architectures and Coherency Protocols on x86-64 Multicore SMP Systems]</ref><br>
	[[File:Nehalem.jpg]]		[[File:Nehalem.jpg]]

Laddaga: /* MESI Protocol */

2012-03-22T01:54:44Z

MESI Protocol

← Older revision		Revision as of 01:54, 22 March 2012
Line 55:		Line 55:
	*'''FlushOpt''': snooped request that indicates that an entire cache block is posted on the bus in order to supply it to another processor. We distinguish FlushOpt from Flush because while Flush is needed for write propagation, FlushOpt is not required for correctness. It is implemented as a performance enhancing feature that can be removed without impacting correctness. It is referred to as an optional block flush cache-to-cache transfer.		*'''FlushOpt''': snooped request that indicates that an entire cache block is posted on the bus in order to supply it to another processor. We distinguish FlushOpt from Flush because while Flush is needed for write propagation, FlushOpt is not required for correctness. It is implemented as a performance enhancing feature that can be removed without impacting correctness. It is referred to as an optional block flush cache-to-cache transfer.
	<br>		<br>
	MESI states under different conditions is shown in the figure below:~~<ref>[http://www.cs.utah.edu/formal_verification/pdf/xiaofang_dissertation.pdf Verification of Hierarchical Cache Coherence Protocols for Futuristic Processors]</ref><~~br>		MESI states under different conditions is shown in the figure below:br>
	[[File:MESI-state.jpg\|550px]]		[[File:MESI-state.jpg\|550px]]
	<br>		<br>

Laddaga: Undo revision 60530 by Laddaga (talk)

2012-03-22T01:53:11Z

Undo revision 60530 by Laddaga (talk)

← Older revision		Revision as of 01:53, 22 March 2012
Line 21:		Line 21:
	*'''Flush''': Flush is a snooped request that indicates that an entire cache block is written back to the main memory by another processor.		*'''Flush''': Flush is a snooped request that indicates that an entire cache block is written back to the main memory by another processor.
	<br>		<br>
	The MSI states under different conditions are shown below:<ref>[http://www.cs.~~uwaterloo~~.ca/~~~brecht~~/~~courses/856/Possible-Readings/multicore~~/~~cache-performance-x86-2009~~.pdf ~~Comparing~~ Cache ~~Architectures and Coherency~~ Protocols ~~on x86-64 Multicore SMP Systems~~]</ref><br>		The MSI states under different conditions are shown below:<ref>[http://www.cs.utah.edu/formal_verification/pdf/xiaofang_dissertation.pdf Verification of Hierarchical Cache Coherence Protocols for Futuristic Processors]</ref><br>
	[[File:MSI-states.jpg\|550px]]<br>		[[File:MSI-states.jpg\|550px]]<br>
	The three states in the MSI protocol are used to directly enforce the cache coherence by allowing only a single processor in the modified state at a given time, allowing multiple processors in the shared state concurrently, and disallowing other processors in the shared state while a processor is in the modified state. In the MSI system, there is a serious drawback that an explicit BusRdX transaction is required for a read followed by a write, even if there are no other shared copies. When a processor reads in and modifies a data item, two bus transactions are generated in this protocol even in the absence of shared copies. The first is a BusRd that gets the cache block to S state, and the second is a BusRdX(or BusUpgr) to invalidate other cached copies. The BusRdX is useless in case there are no other shared copies. <br>		The three states in the MSI protocol are used to directly enforce the cache coherence by allowing only a single processor in the modified state at a given time, allowing multiple processors in the shared state concurrently, and disallowing other processors in the shared state while a processor is in the modified state. In the MSI system, there is a serious drawback that an explicit BusRdX transaction is required for a read followed by a write, even if there are no other shared copies. When a processor reads in and modifies a data item, two bus transactions are generated in this protocol even in the absence of shared copies. The first is a BusRd that gets the cache block to S state, and the second is a BusRdX(or BusUpgr) to invalidate other cached copies. The BusRdX is useless in case there are no other shared copies. <br>

Laddaga: /* MSI Protocol */

2012-03-22T01:51:12Z

MSI Protocol

← Older revision		Revision as of 01:51, 22 March 2012
Line 21:		Line 21:
	*'''Flush''': Flush is a snooped request that indicates that an entire cache block is written back to the main memory by another processor.		*'''Flush''': Flush is a snooped request that indicates that an entire cache block is written back to the main memory by another processor.
	<br>		<br>
	The MSI states under different conditions are shown below:<ref>[http://www.cs.~~utah~~.~~edu~~/~~formal_verification~~/~~pdf~~/~~xiaofang_dissertation~~.pdf ~~Verification of Hierarchical~~ Cache ~~Coherence~~ Protocols ~~for Futuristic Processors~~]</ref><br>		The MSI states under different conditions are shown below:<ref>[http://www.cs.uwaterloo.ca/~brecht/courses/856/Possible-Readings/multicore/cache-performance-x86-2009.pdf Comparing Cache Architectures and Coherency Protocols on x86-64 Multicore SMP Systems]</ref><br>
	[[File:MSI-states.jpg\|550px]]<br>		[[File:MSI-states.jpg\|550px]]<br>
	The three states in the MSI protocol are used to directly enforce the cache coherence by allowing only a single processor in the modified state at a given time, allowing multiple processors in the shared state concurrently, and disallowing other processors in the shared state while a processor is in the modified state. In the MSI system, there is a serious drawback that an explicit BusRdX transaction is required for a read followed by a write, even if there are no other shared copies. When a processor reads in and modifies a data item, two bus transactions are generated in this protocol even in the absence of shared copies. The first is a BusRd that gets the cache block to S state, and the second is a BusRdX(or BusUpgr) to invalidate other cached copies. The BusRdX is useless in case there are no other shared copies. <br>		The three states in the MSI protocol are used to directly enforce the cache coherence by allowing only a single processor in the modified state at a given time, allowing multiple processors in the shared state concurrently, and disallowing other processors in the shared state while a processor is in the modified state. In the MSI system, there is a serious drawback that an explicit BusRdX transaction is required for a read followed by a write, even if there are no other shared copies. When a processor reads in and modifies a data item, two bus transactions are generated in this protocol even in the absence of shared copies. The first is a BusRd that gets the cache block to S state, and the second is a BusRdX(or BusUpgr) to invalidate other cached copies. The BusRdX is useless in case there are no other shared copies. <br>