Scalable Coherent Interface - Revision history

Mpsenn: /* Race Conditions */ adding more sections

2011-04-15T19:55:08Z

Race Conditions: adding more sections

← Older revision		Revision as of 19:55, 15 April 2011
Line 59:		Line 59:
	In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.		In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.

			==Handling Races due to Non-Instantaneous Processing of a Request==
	The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved in three ways:		The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved in three ways:

Line 64:		Line 65:
	*The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.		*The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.
	*The directory always services requests, and the requests are stored and serialized at the cache head.		*The directory always services requests, and the requests are stored and serialized at the cache head.

			See the Solihin text, section 11.4.2 for more information.

			==Handling Races due to Out-of-Sync Directory State==


			See the Solihin text, section 11.4.1 for more information.

	Why so many states needed?		Why so many states needed?

Mnmiskie: /* Race Conditions */

2011-04-15T19:45:17Z

Race Conditions

← Older revision		Revision as of 19:45, 15 April 2011
Line 64:		Line 64:
	*The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.		*The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.
	*The directory always services requests, and the requests are stored and serialized at the cache head.		*The directory always services requests, and the requests are stored and serialized at the cache head.

			Why so many states needed?
			Why pending states needed?

	=References=		=References=

Mpsenn: adding design goals to top

2011-04-15T19:40:01Z

adding design goals to top

← Older revision		Revision as of 19:40, 15 April 2011
Line 1:		Line 1:
	SCI is an IEEE standard for shared-memory multiprocessing. The standard was approved in 1992. View the [http://en.wikipedia.org/wiki/Scalable_Coherent_Interface#History SCI Wikipedia article] for more information on the interface's history. The article covers the cache-coherence portions of the IEEE standard.		SCI is an IEEE standard for shared-memory multiprocessing. The standard was approved in 1992. View the [http://en.wikipedia.org/wiki/Scalable_Coherent_Interface#History SCI Wikipedia article] for more information on the interface's history. The article covers the cache-coherence portions of the IEEE standard.

			SCI design goals include
			*Scalability, so that the same mechanisms can be used in high-volume, single-processor (or few-processor) systems such as one might find in desktop machines, as well as in large, highly parallel multiprocessors (next-generation supercomputers);
			*Coherence, to support the efficient use of cache memories in the most general and easiest-to-use multiprocessor model, distributed shared memory; and
			*An interface, a standardized open communication architecture that allows products from multiple vendors to be incorporated into one system and interoperate smoothly.

	=General Operation=		=General Operation=

Mnmiskie: /* Race Conditions */

2011-04-15T19:38:08Z

Race Conditions

← Older revision		Revision as of 19:38, 15 April 2011
Line 53:		Line 53:
	=Race Conditions=		=Race Conditions=
	In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.		In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.


	The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved in three ways:		The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved in three ways:


	*The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.		*The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.

Mnmiskie: /* Race Conditions */

2011-04-15T19:37:35Z

Race Conditions

← Older revision		Revision as of 19:37, 15 April 2011
Line 55:		Line 55:


	The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved ~~by the following methods~~:		The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved in three ways:


	1. The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.		*The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.
			*The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.
	2. The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.		*The directory always services requests, and the requests are stored and serialized at the cache head.

	3. The directory always services requests, and the requests are stored and serialized at the cache head.

	=References=		=References=

Mnmiskie: /* Race Conditions */

2011-04-15T19:36:58Z

Race Conditions

← Older revision		Revision as of 19:36, 15 April 2011
Line 53:		Line 53:
	=Race Conditions=		=Race Conditions=
	In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.		In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.


	The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved by the following methods:		The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved by the following methods:


	1. The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.		1. The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.
	2. The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.
			2. The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.

	3. The directory always services requests, and the requests are stored and serialized at the cache head.		3. The directory always services requests, and the requests are stored and serialized at the cache head.

Mnmiskie: /* Race Conditions */

2011-04-15T19:36:35Z

Race Conditions

← Older revision		Revision as of 19:36, 15 April 2011
Line 52:		Line 52:

	=Race Conditions=		=Race Conditions=
	In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states.		In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states. One of the additional states is the busy state.

			The simplest kind of race conditions results from simultaneous write requests to the same block. If both requests proceed in parallel, the system will fail. This problem can avoided by serializing the requests. This is solved by the following methods:

			1. The directory only accepts one request and then enters the busy state. Future requests are denied until the busy state is left.
			2. The home node stores the requests in the order received and services them in order, utilizing the busy state to know when a write has finished.
			3. The directory always services requests, and the requests are stored and serialized at the cache head.

	=References=		=References=

Mnmiskie: /* Race Conditions */

2011-04-15T19:09:26Z

Race Conditions

← Older revision		Revision as of 19:09, 15 April 2011
Line 52:		Line 52:

	=Race Conditions=		=Race Conditions=
			In addition to the above stabe states, the existance of race conditions require numerous pending cache and memory states.

	=References=		=References=

Mpsenn: /* Linked List */

2011-04-15T19:00:38Z

Linked List

← Older revision		Revision as of 19:00, 15 April 2011
Line 10:		Line 10:

	==Linked List==		==Linked List==
	Each cache that holds a given block is a member of that block's linked list. When a new cache requests a block, the memory supplies the id of the '''Head cache'''. Each cache in the list contains a link to the previous cache and the next cache in the list. In this way, the list is distributed.		Each cache that holds a given block is a member of that block's linked list. When a new cache requests a block, the memory supplies the id of the '''Head cache'''. Each cache in the list contains a link to the previous cache and the next cache in the list. The last cache in the list is the '''Tail cache'''. In this way, the list is distributed.

	Because SCI is an invalidation protocol, the linked list is cleared upon every write. First, the writing cache adds itself to the head of the list, then indicates to the next cache that it is invalidating the block.		Because SCI is an invalidation protocol, the linked list is cleared upon every write. First, the writing cache adds itself to the head of the list, then indicates to the next cache that it is invalidating the block.

	==Cache Lines==		==Cache Lines==

Mpsenn: /* General Operation */ adding information on linked list and cache line

2011-04-15T18:59:51Z

General Operation: adding information on linked list and cache line

← Older revision		Revision as of 18:59, 15 April 2011
Line 2:		Line 2:

	=General Operation=		=General Operation=
			Cache coherence in SCI uses several main components to ensure reliability.

	SCI operates by using directories in every processor's memory. When a memory block has not been cached, the directory holds this block in the Home state, signifying that the block is at home. After a read request, the memory holds this block in the Fresh state and will supply the data immediately to any requesting cache. After a write request, the memory holds the block in the Gone state. The memory does not supply the data to further requesting caches, but instead supplies the cache with ~~an identifier for~~ a cache that holds this data.		==Memory Directory==
			SCI operates by using directories in every processor's memory. When a memory block has not been cached, the directory holds this block in the '''Home state''', signifying that the block is at home. After a read request, the memory holds this block in the '''Fresh state''' and will supply the data immediately to any requesting cache. After a write request, the memory holds the block in the '''Gone state'''. The memory does not supply the data to further requesting caches, but instead supplies the cache with a link to a cache that holds this data.

	~~This~~ cache is ~~called~~ the Head cache. ~~Other caches that hold~~ the ~~data are stored~~ in a distributed linked list, ~~with each~~ cache ~~pointing~~ to the ~~previous and~~ next ~~caches in~~ the list.		The directory can be expected to take up to 4% of the total memory space.

			==Linked List==
			Each cache that holds a given block is a member of that block's linked list. When a new cache requests a block, the memory supplies the id of the '''Head cache'''. Each cache in the list contains a link to the previous cache and the next cache in the list. In this way, the list is distributed.

			Because SCI is an invalidation protocol, the linked list is cleared upon every write. First, the writing cache adds itself to the head of the list, then indicates to the next cache that it is invalidating the block.

			==Cache Lines==
			Besides the data for the linked list, each cache line needs to store the standard cache information (i.e. tag). This information is expected to be about 7% of the total cache memory.

	=Cache State Machine=		=Cache State Machine=