COMP 3000 Essay 2 2010 Question 1 - Revision history

Soma: Protected "COMP 3000 Essay 2 2010 Question 1" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-12-03T19:45:56Z

Protected "COMP 3000 Essay 2 2010 Question 1" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 19:45, 3 December 2010
(No difference)

Daniel.beimers: /* Conclusion: Sections 6 & 7 */

2010-12-03T04:40:20Z

Conclusion: Sections 6 & 7

← Older revision		Revision as of 04:40, 3 December 2010
Line 81:		Line 81:

	===Conclusion: ''Sections 6 & 7''===		===Conclusion: ''Sections 6 & 7''===
	Each testing case has the same specific parameters, with the only changes being from the stock kernel to the PK kernel. ~~There was one~~ assumption that held true for all tests, the I/O bottleneck was irrelevant to the tests. Thus the conclusion has no concerns with respect to the content.		Each testing case has the same specific parameters, with the only changes being from the stock kernel to the PK kernel. The assumption that held true for all tests was that the I/O bottleneck was irrelevant to the tests. Thus the conclusion has no concerns with respect to the content of the paper.

	=References=		=References=

Daniel.beimers: /* gmake: Section 5.6 */

2010-12-03T04:39:12Z

gmake: Section 5.6

← Older revision		Revision as of 04:39, 3 December 2010
Line 78:		Line 78:

	===gmake: ''Section 5.6''===		===gmake: ''Section 5.6''===
	Since the inherent nature of gmake makes it quite parallel, the testing and updating that were attempted on gmake resulted in essentially the same scalability results for both the stock and modified kernel. The only change that was found was that gmake spent slightly less time at the system level because of the changes that were made to the system's caching. As stated in the paper, the execution time of gmake relies quite heavily on the compiler that is ~~uses~~ with gmake, so depending on which compiler was chosen, gmake could run worse or even slightly better. In any case, there seems to be no fairness concerns when it comes to the scalability testing of gmake as the same application load-out was used for all of the tests.<sup>[[#Foot1\|1]]</sup>		Since the inherent nature of gmake makes it quite parallel, the testing and updating that were attempted on gmake resulted in essentially the same scalability results for both the stock and modified kernel. The only change that was found was that gmake spent slightly less time at the system level because of the changes that were made to the system's caching. As stated in the paper, the execution time of gmake relies quite heavily on the compiler that is used with gmake, so depending on which compiler was chosen, gmake could run worse or even slightly better. In any case, there seems to be no fairness concerns when it comes to the scalability testing of gmake as the same application load-out was used for all of the tests.<sup>[[#Foot1\|1]]</sup>

	===Conclusion: ''Sections 6 & 7''===		===Conclusion: ''Sections 6 & 7''===

Daniel.beimers: /* Apache: Section 5.4 */

2010-12-03T04:38:13Z

Apache: Section 5.4

← Older revision		Revision as of 04:38, 3 December 2010
Line 75:		Line 75:

	===Apache: ''Section 5.4''===		===Apache: ''Section 5.4''===
	Linux has a built in kernel flaw where network packets are forced to travel though multiple queues before they arrive at queue where they can be processed by the application. This imposes significant costs on multi-core systems due to queue locking ~~costs~~. This flaw inherently diminishes the performance of Apache on multi-core ~~system~~ due to multiple threads spread across cores being forced to deal with these mutex (mutual exclusion) costs. For the sake of this experiment Apache had a separate instance on every core listening on different ports which is not a practical real world application but merely an attempt to implement better parallel execution on a traditional kernel. The patched kernel implementation of the network stack is also specific to the problem at hand, which is processing multiple short lived connections across multiple cores. Although this provides a performance increase in the given scenario, in more general applications network performance might suffer. These tests were also rigged to avoid bottlenecks in place by network and file storage hardware. Meaning, making the proposed modifications to the kernel ~~wont~~ necessarily produce the same increase in productivity as described in the article. This is very much evident in the ~~test~~ where performance degrades past 36 cores due to limitation of the networking hardware.<sup>[[#Foot1\|1]]</sup>		Linux has a built in kernel flaw where network packets are forced to travel though multiple queues before they arrive at queue where they can be processed by the application. This imposes significant costs on multi-core systems due to the cost associated with queue locking. This flaw inherently diminishes the performance of Apache on multi-core systems due to multiple threads spread across cores being forced to deal with these mutex (mutual exclusion) costs. For the sake of this experiment, Apache had a separate instance on every core listening on different ports, which is not a practical real world application, but merely an attempt to implement better parallel execution on a traditional kernel. The patched kernel implementation of the network stack is also specific to the problem at hand, which is processing multiple short lived connections across multiple cores. Although this provides a performance increase in the given scenario, in more general applications network performance might suffer. These tests were also rigged to avoid bottlenecks in place by network and file storage hardware. Meaning, making the proposed modifications to the kernel won't necessarily produce the same increase in productivity as described in the article. This is very much evident in the tests where performance degrades past 36 cores due to limitation of the networking hardware.<sup>[[#Foot1\|1]]</sup>

	===gmake: ''Section 5.6''===		===gmake: ''Section 5.6''===

Daniel.beimers: /* memcached: Section 5.3 */

2010-12-03T04:35:03Z

memcached: Section 5.3

← Older revision		Revision as of 04:35, 3 December 2010
Line 72:		Line 72:

	===memcached: ''Section 5.3''===		===memcached: ''Section 5.3''===
	memcached is treated with near perfect fairness in the paper. Its an in-memory service, so the ignored storage IO bottleneck does not affect it at all. Likewise the "stock" and "PK" implementations are given the same test suite, so there is no advantage given to either. memcached itself is non-scalable, so the MIT team was forced to run one instance per-core to keep up throughput. The FAQ at memcached.org's wiki suggests using multiple implementations per-server as a work around to another problem, which implies that there is no great problem with running multiple servers on one machine.<sup>[[#Foot7\|7]]</sup>		memcached is treated with near perfect fairness in the paper. Its an in-memory service, so the ignored storage I/O bottleneck does not affect it at all. Likewise the "stock" and "PK" implementations are given the same test suite, so there is no advantage given to either. memcached itself is non-scalable, so the MIT team was forced to run one instance per-core to keep up throughput. The FAQ at memcached.org's wiki suggests using multiple implementations per-server as a work around to another problem, which implies that there is no great problem with running multiple servers on one machine.<sup>[[#Foot7\|7]]</sup>

	===Apache: ''Section 5.4''===		===Apache: ''Section 5.4''===

Daniel.beimers: /* Critique */

2010-12-03T04:34:45Z

Critique

← Older revision		Revision as of 04:34, 3 December 2010
Line 69:		Line 69:

	=Critique=		=Critique=
	Aside from a few acronyms that were unexplained (e.g. Linux TLB) the paper has no real stylistic problems.		Aside from a few acronyms that were unexplained (e.g. Linux TLB), the paper has no real stylistic problems.

	===memcached: ''Section 5.3''===		===memcached: ''Section 5.3''===

Rannath: /* Critique */

2010-12-03T04:32:59Z

Critique

← Older revision		Revision as of 04:32, 3 December 2010
Line 71:		Line 71:
	Aside from a few acronyms that were unexplained (e.g. Linux TLB) the paper has no real stylistic problems.		Aside from a few acronyms that were unexplained (e.g. Linux TLB) the paper has no real stylistic problems.

	==memcached: ''Section 5.3''==		===memcached: ''Section 5.3''===
	memcached is treated with near perfect fairness in the paper. Its an in-memory service, so the ignored storage IO bottleneck does not affect it at all. Likewise the "stock" and "PK" implementations are given the same test suite, so there is no advantage given to either. memcached itself is non-scalable, so the MIT team was forced to run one instance per-core to keep up throughput. The FAQ at memcached.org's wiki suggests using multiple implementations per-server as a work around to another problem, which implies that there is no great problem with running multiple servers on one machine.<sup>[[#Foot7\|7]]</sup>		memcached is treated with near perfect fairness in the paper. Its an in-memory service, so the ignored storage IO bottleneck does not affect it at all. Likewise the "stock" and "PK" implementations are given the same test suite, so there is no advantage given to either. memcached itself is non-scalable, so the MIT team was forced to run one instance per-core to keep up throughput. The FAQ at memcached.org's wiki suggests using multiple implementations per-server as a work around to another problem, which implies that there is no great problem with running multiple servers on one machine.<sup>[[#Foot7\|7]]</sup>

	==Apache: ''Section 5.4''==		===Apache: ''Section 5.4''===
	Linux has a built in kernel flaw where network packets are forced to travel though multiple queues before they arrive at queue where they can be processed by the application. This imposes significant costs on multi-core systems due to queue locking costs. This flaw inherently diminishes the performance of Apache on multi-core system due to multiple threads spread across cores being forced to deal with these mutex (mutual exclusion) costs. For the sake of this experiment Apache had a separate instance on every core listening on different ports which is not a practical real world application but merely an attempt to implement better parallel execution on a traditional kernel. The patched kernel implementation of the network stack is also specific to the problem at hand, which is processing multiple short lived connections across multiple cores. Although this provides a performance increase in the given scenario, in more general applications network performance might suffer. These tests were also rigged to avoid bottlenecks in place by network and file storage hardware. Meaning, making the proposed modifications to the kernel wont necessarily produce the same increase in productivity as described in the article. This is very much evident in the test where performance degrades past 36 cores due to limitation of the networking hardware.<sup>[[#Foot1\|1]]</sup>		Linux has a built in kernel flaw where network packets are forced to travel though multiple queues before they arrive at queue where they can be processed by the application. This imposes significant costs on multi-core systems due to queue locking costs. This flaw inherently diminishes the performance of Apache on multi-core system due to multiple threads spread across cores being forced to deal with these mutex (mutual exclusion) costs. For the sake of this experiment Apache had a separate instance on every core listening on different ports which is not a practical real world application but merely an attempt to implement better parallel execution on a traditional kernel. The patched kernel implementation of the network stack is also specific to the problem at hand, which is processing multiple short lived connections across multiple cores. Although this provides a performance increase in the given scenario, in more general applications network performance might suffer. These tests were also rigged to avoid bottlenecks in place by network and file storage hardware. Meaning, making the proposed modifications to the kernel wont necessarily produce the same increase in productivity as described in the article. This is very much evident in the test where performance degrades past 36 cores due to limitation of the networking hardware.<sup>[[#Foot1\|1]]</sup>

	==gmake: ''Section 5.6''==		===gmake: ''Section 5.6''===
	Since the inherent nature of gmake makes it quite parallel, the testing and updating that were attempted on gmake resulted in essentially the same scalability results for both the stock and modified kernel. The only change that was found was that gmake spent slightly less time at the system level because of the changes that were made to the system's caching. As stated in the paper, the execution time of gmake relies quite heavily on the compiler that is uses with gmake, so depending on which compiler was chosen, gmake could run worse or even slightly better. In any case, there seems to be no fairness concerns when it comes to the scalability testing of gmake as the same application load-out was used for all of the tests.<sup>[[#Foot1\|1]]</sup>		Since the inherent nature of gmake makes it quite parallel, the testing and updating that were attempted on gmake resulted in essentially the same scalability results for both the stock and modified kernel. The only change that was found was that gmake spent slightly less time at the system level because of the changes that were made to the system's caching. As stated in the paper, the execution time of gmake relies quite heavily on the compiler that is uses with gmake, so depending on which compiler was chosen, gmake could run worse or even slightly better. In any case, there seems to be no fairness concerns when it comes to the scalability testing of gmake as the same application load-out was used for all of the tests.<sup>[[#Foot1\|1]]</sup>

	==Conclusion: ''Sections 6 & 7''==		===Conclusion: ''Sections 6 & 7''===
	Each testing case has the same specific parameters, with the only changes being from the stock kernel to the PK kernel. There was one assumption that held true for all tests, the I/O bottleneck was irrelevant to the tests. Thus the conclusion has no concerns with respect to the content.		Each testing case has the same specific parameters, with the only changes being from the stock kernel to the PK kernel. There was one assumption that held true for all tests, the I/O bottleneck was irrelevant to the tests. Thus the conclusion has no concerns with respect to the content.

Rannath: /* Critique */

2010-12-03T04:32:30Z

Critique

@@ Line 69: / Line 69: @@
 =Critique=
-What is good and not-so-good about this paper? You may discuss both the style and content; be sure to ground your discussion with specific references. Simple assertions that something is good or bad is not enough - you must explain why.
+Aside from a few acronyms that were unexplained (e.g. Linux TLB) the paper has no real stylistic problems.
 =References=

Daniel.beimers: /* Per-Core Data Structures: Section 4.5 */

2010-12-03T04:19:17Z

Per-Core Data Structures: Section 4.5

← Older revision		Revision as of 04:19, 3 December 2010
Line 44:		Line 44:

	====Per-Core Data Structures: ''Section 4.5''====		====Per-Core Data Structures: ''Section 4.5''====
	Three centralized data structures were causing bottlenecks due to lock contention - a per-superblock list of open files, vfsmount table, and the packet buffers free list. Each data structure was decentralized to per-core versions of itself. In the case of vfsmount the central data structure was maintained, and any per-core misses got written from the central table to the per-core table.<sup>[[#Foot1\|1]]</sup>		Three centralized data structures were causing bottlenecks due to lock contention - a per-superblock list of open files, vfsmount table, and the packet buffers free list. Each data structure was decentralized to per-core versions of itself. In the case of vfsmount, the central data structure was maintained and any per-core misses got written from the central table to the per-core table.<sup>[[#Foot1\|1]]</sup>

	====Eliminating false sharing: ''Section 4.6''====		====Eliminating false sharing: ''Section 4.6''====

Daniel.beimers: /* Lock-free comparison & Avoiding unnecessary locking: Section 4.4 & 4.7 */

2010-12-03T04:18:50Z

Lock-free comparison & Avoiding unnecessary locking: Section 4.4 & 4.7

← Older revision		Revision as of 04:18, 3 December 2010
Line 39:		Line 39:

	====Lock-free comparison & Avoiding unnecessary locking: ''Section 4.4 & 4.7''====		====Lock-free comparison & Avoiding unnecessary locking: ''Section 4.4 & 4.7''====
	The traditional Linux kernel has very low scalability for name lookups in the directory entry cache. This means there is reduced performance in returning information pertaining to a specific file path when there are multiple threads trying to access files in common parent directories due to the kernel serializing the process. This problem is solved in the patched kernel by introducing a new counter to keep track of threads actively looking at the directory entry cache. If a certain thread threatens an entry currently in use by another, the default locking protocol is used to avoid race conditions. If the activities have no bearing on each other the situation is rightfully ignored allowing for much faster access to different different entries in the directory entry cache.<sup>[[#Foot1\|1]]</sup>		The traditional Linux kernel has very low scalability for name lookups in the directory entry cache. This means there is reduced performance in returning information pertaining to a specific file path when there are multiple threads trying to access files in common parent directories due to the kernel serializing the process. This problem is solved in the patched kernel by introducing a new counter to keep track of threads actively looking at the directory entry cache. If a certain thread threatens an entry currently in use by another, the default locking protocol is used to avoid race conditions. If the activities have no bearing on each other, the situation is rightfully ignored, allowing for much faster access to different different entries in the directory entry cache.<sup>[[#Foot1\|1]]</sup>

	There are many other locks/mutexes that have special cases where they don't need to lock. Others can be split from locking the whole data structure to locking a part of it. Both these changes remove or reduce bottlenecks.<sup>[[#Foot1\|1]]</sup>		There are many other locks/mutexes that have special cases where they don't need to lock. Others can be split from locking the whole data structure to locking a part of it. Both these changes remove or reduce bottlenecks.<sup>[[#Foot1\|1]]</sup>