COMP 3000 Essay 2 2010 Question 3 - Revision history

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

2010-12-03T19:44:17Z

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

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

Rarteaga: /* Critique: */

2010-12-03T11:06:12Z

Critique:

← Older revision		Revision as of 11:06, 3 December 2010
Line 141:		Line 141:
	outcome when using specialized GPUs, like NVIDIA's Tesla GPUs for example. Would FlexSC's scheduler be able to take advantage of the additional cores, and hence use them for<br>		outcome when using specialized GPUs, like NVIDIA's Tesla GPUs for example. Would FlexSC's scheduler be able to take advantage of the additional cores, and hence use them for<br>
	specialized purposes ?		specialized purposes ?

			===Style===
			The overall reading of the paper was fairly understandable. Some deeper knowledge of System Calls and Synchronous systems is definitely recommended, almost necessary for this papers true comprehension. The paper was explained very well and even though we did need to research some specific background or similar topics, it was a well written paper. A reader with a base knowledge of Operation Systems can understand this paper for the core concept and know where to go to investigate further details and descriptions that are lacking in the paper.

	== Related Work: ==		== Related Work: ==

Rarteaga: /* Implementation and Statistics */

2010-12-03T10:59:25Z

Implementation and Statistics

← Older revision		Revision as of 10:59, 3 December 2010
Line 99:		Line 99:
	Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.		Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.

	Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can ~~being~~ implementing this system into our computers we use every day and begin to see immediate results.		Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can begin implementing this system into our computers we use every day and begin to see immediate results. Now this effect of the statistics occurs when multiple cores occur as well when batching occurs numerous times. Otherwise if these two factors are very small then no change occurs or even a decrease in efficiency can occur.

	== Critique: ==		== Critique: ==

Tafatah: /* Implementation and Statistics */

2010-12-03T01:58:35Z

Implementation and Statistics

← Older revision		Revision as of 01:58, 3 December 2010
Line 92:		Line 92:

	===Implementation and Statistics===		===Implementation and Statistics===
	Up until this point, we have discussed and illustrated the theory behind FlexSC's logic patterns. However, it is also as important to demonstrate the practical and statistical results during implementation. FlexSC's implementation has shown a very large leap from ~~todays~~ synchronous system call method currently in use.		Up until this point, we have discussed and illustrated the theory behind FlexSC's logic patterns. However, it is also as important to demonstrate the practical and statistical results during implementation. FlexSC's implementation has shown a very large leap from today's synchronous system call method currently in use.
	Firstly, demonstration of the current synchronous systems statistics will be discussed. The data collected by the researchers show that the System Calls cause a large delay in the User IPC(Interprocess Communication) between 20% and 60%. To get a general idea of how many instructions are executed in one system call ~~here~~ we name a few with their corresponding number of instructions. According to the researchers of this paper, pread(),pwrite(), open+close() require 3739, 5689 and 6631 instructions respectively. Therefore, these system calls, are not minuscule lines of code, that can be overlooked, they ~~take~~ a large amount of ~~Time devoted to them~~, hence FlexSC ~~attempts~~ to lower this overall value by methods mentioned above in the paper such as system call batching.		Firstly, demonstration of the current synchronous systems statistics will be discussed. The data collected by the researchers show that the System Calls cause a large delay in the User IPC(Interprocess Communication) between 20% and 60%. To get a general idea of how many instructions are executed in one system call, we name a few with their corresponding number of instructions. According to the researchers of this paper, pread(), pwrite(), open+close() require 3739, 5689 and 6631 instructions respectively. Therefore, these system calls, are not minuscule lines of code, that can be overlooked, they consume a large amount of time, hence FlexSC's attempt to lower this overall value by methods mentioned above in the paper such as system call batching.

	On a single core, the System-Less Batching produces an improved time from 55 nanoseconds to about 35 nanoseconds once 15 or more batch requests have been utilized. Moreover, the throughput(requests/sec) shows a dramatic increase of 10,000 and more in Apache throughput of Linux. This throughput increases with the more cores implemented in the system. This demonstrates ~~our~~ theory of how the FlexSC's main application improvements in systems implementing multiple cores.		On a single core, the System-Less Batching produces an improved time from 55 nanoseconds to about 35 nanoseconds once 15 or more batch requests have been utilized. Moreover, the throughput(requests/sec) shows a dramatic increase of 10,000 and more in Apache throughput of Linux. This throughput increases with the more cores implemented in the system. This demonstrates the theory of how the FlexSC's main application improvements in systems implementing multiple cores.

	Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now~~. Hence, where the system was once spending time doing nothing, it is now being put to get use and running the User Space with more aid~~. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.		Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.

	Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can being implementing this system into our computers we use every day and begin to see results ~~in front of our eyes. ***i'm not done writing this section, will be back to work on it in an hour, still need some fixing here and there i know~~.		Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can being implementing this system into our computers we use every day and begin to see immediate results.

	== Critique: ==		== Critique: ==

Rarteaga: /* Implementation and Statistics */

2010-12-02T21:24:50Z

Implementation and Statistics

← Older revision		Revision as of 21:24, 2 December 2010
Line 99:		Line 99:
	Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Hence, where the system was once spending time doing nothing, it is now being put to get use and running the User Space with more aid. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.		Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Hence, where the system was once spending time doing nothing, it is now being put to get use and running the User Space with more aid. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.

	Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can being implementing this system into our computers we use every day and begin to see results in front of our eyes. ***i'm not writing this section, will be back to work on it in an hour, still need some fixing here and there i know.		Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can being implementing this system into our computers we use every day and begin to see results in front of our eyes. ***i'm not done writing this section, will be back to work on it in an hour, still need some fixing here and there i know.

	== Critique: ==		== Critique: ==

Rarteaga at 21:24, 2 December 2010

2010-12-02T21:24:30Z

← Older revision		Revision as of 21:24, 2 December 2010
Line 90:		Line 90:

	FlexSC Threads implement an M-on-N threading model, where M is the number of user based threads and N is the number of syscall threads, M being greater than N [1]. This is similar to one of the common styles of implementing threads, referred to as M:N model [22], where M represents user space threads, and N represents Kernel threads. The M-on-N model however uses FlexSC’s exception-less system call mechanism (transparently), i.e. its inner workings differ, from the otherwise typical M:N model. The M-on-N model takes advantage of maximizing the number of user space threads switching. In other words, as long as a user space thread is ready, work will continue in user space, minimizing thus the time spent on blocking.		FlexSC Threads implement an M-on-N threading model, where M is the number of user based threads and N is the number of syscall threads, M being greater than N [1]. This is similar to one of the common styles of implementing threads, referred to as M:N model [22], where M represents user space threads, and N represents Kernel threads. The M-on-N model however uses FlexSC’s exception-less system call mechanism (transparently), i.e. its inner workings differ, from the otherwise typical M:N model. The M-on-N model takes advantage of maximizing the number of user space threads switching. In other words, as long as a user space thread is ready, work will continue in user space, minimizing thus the time spent on blocking.

			===Implementation and Statistics===
			Up until this point, we have discussed and illustrated the theory behind FlexSC's logic patterns. However, it is also as important to demonstrate the practical and statistical results during implementation. FlexSC's implementation has shown a very large leap from todays synchronous system call method currently in use.
			Firstly, demonstration of the current synchronous systems statistics will be discussed. The data collected by the researchers show that the System Calls cause a large delay in the User IPC(Interprocess Communication) between 20% and 60%. To get a general idea of how many instructions are executed in one system call here we name a few with their corresponding number of instructions. According to the researchers of this paper, pread(),pwrite(), open+close() require 3739, 5689 and 6631 instructions respectively. Therefore, these system calls, are not minuscule lines of code, that can be overlooked, they take a large amount of Time devoted to them, hence FlexSC attempts to lower this overall value by methods mentioned above in the paper such as system call batching.

			On a single core, the System-Less Batching produces an improved time from 55 nanoseconds to about 35 nanoseconds once 15 or more batch requests have been utilized. Moreover, the throughput(requests/sec) shows a dramatic increase of 10,000 and more in Apache throughput of Linux. This throughput increases with the more cores implemented in the system. This demonstrates our theory of how the FlexSC's main application improvements in systems implementing multiple cores.

			Furthermore, on a 4 core system, 14% of the original 50% idle time is being used in the User Space now. Hence, where the system was once spending time doing nothing, it is now being put to get use and running the User Space with more aid. Latency as well is decreased by half of the original time on 1,2 and 4 core implementations. Also very interesting test case the researchers investigated was the idea of having numerous requests occurring at once in the system. They chose to execute 256 synchronous requests in the system and what they came to find is that FlexSC's method is 60ms faster than the current synchronous method and continually increases with the more cores in use.

			Through the different methods being executed by the FlexSC's concepts, the statistics taken of the system demonstrates that their theory does hold in practice. This illustrates that we can being implementing this system into our computers we use every day and begin to see results in front of our eyes. ***i'm not writing this section, will be back to work on it in an hour, still need some fixing here and there i know.

	== Critique: ==		== Critique: ==

Tafatah: /* FlexSC Threads */

2010-12-02T18:37:17Z

FlexSC Threads

← Older revision		Revision as of 18:37, 2 December 2010
Line 89:		Line 89:
	As mentioned above, FlexSC threads are a key component of the exception-less system call interface. FlexSC threads transform regular, synchronous system calls into exception-less system calls and are compatible with both the POSIX and default Linux thread libraries. This means that FlexSC Threads are immediately capable of running multi-threaded Linux applications with no modifications. The intended use of these threads is with server-type applications which contain many user-mode threads. In order to accomodate multiple user-mode threads, the FlexSC interface provides a syscall page for each core of a system. In this manner, multiple user-mode threads can be multiplexed onto a single syscall page which in turn has a single kernel level thread to facilitate execution of the system calls. Programming with FlexSC threads can be compared to event-driven programming as interactions are not guaranteed to be sequential. This does increase the complexity of programming for an exception-less system call interface as compared to the relatively simple synchronous system call interface.[1][2][3]<br><br>		As mentioned above, FlexSC threads are a key component of the exception-less system call interface. FlexSC threads transform regular, synchronous system calls into exception-less system calls and are compatible with both the POSIX and default Linux thread libraries. This means that FlexSC Threads are immediately capable of running multi-threaded Linux applications with no modifications. The intended use of these threads is with server-type applications which contain many user-mode threads. In order to accomodate multiple user-mode threads, the FlexSC interface provides a syscall page for each core of a system. In this manner, multiple user-mode threads can be multiplexed onto a single syscall page which in turn has a single kernel level thread to facilitate execution of the system calls. Programming with FlexSC threads can be compared to event-driven programming as interactions are not guaranteed to be sequential. This does increase the complexity of programming for an exception-less system call interface as compared to the relatively simple synchronous system call interface.[1][2][3]<br><br>

	FlexSC Threads ~~implements~~ an M-on-N threading model, where M is the number of user based threads and N is the number of syscall threads, M being greater than N [1]. This is similar to one of the common styles of implementing threads, referred to as M:N model [22], where M represents user space threads, and N represents Kernel threads. The M-on-N model however uses FlexSC’s exception-less system call mechanism (transparently), i.e. its inner workings differ, from the otherwise typical M:N model. The M-on-N model takes advantage of maximizing the number of user space threads switching. In other words, as long as a user space thread is ready, work will continue in user space, minimizing thus the time spent on blocking.		FlexSC Threads implement an M-on-N threading model, where M is the number of user based threads and N is the number of syscall threads, M being greater than N [1]. This is similar to one of the common styles of implementing threads, referred to as M:N model [22], where M represents user space threads, and N represents Kernel threads. The M-on-N model however uses FlexSC’s exception-less system call mechanism (transparently), i.e. its inner workings differ, from the otherwise typical M:N model. The M-on-N model takes advantage of maximizing the number of user space threads switching. In other words, as long as a user space thread is ready, work will continue in user space, minimizing thus the time spent on blocking.

	== Critique: ==		== Critique: ==

Tafatah: /* Background Concepts: */

2010-12-02T18:33:40Z

Background Concepts:

← Older revision		Revision as of 18:33, 2 December 2010
Line 6:		Line 6:
	== Background Concepts: ==		== Background Concepts: ==

	In order to fully understand the FlexSC paper, it is essential to understand the key concepts that are discussed within the paper. Here listed below, are the main concepts required to fully comprehend the paper. It is more vital to the reader to understand the core ideas of these ~~defintions~~ along with the underlying motivation for ~~there existance~~, ~~then~~ to understand the miniscule details of their processes.		In order to fully understand the FlexSC paper, it is essential to understand the key concepts that are discussed within the paper. Here listed below, are the main concepts required to fully comprehend the paper. It is more vital to the reader to understand the core ideas of these definitions, along with the underlying motivation for their existence, than to understand the miniscule details of their processes.

	===System Call===		===System Call===
Line 12:		Line 12:

	===Mode Switch===		===Mode Switch===
	<b>Mode Switches</b> speak of moving from one medium to another. Specifically moving from the User Space mode to the Kernel mode or Kernel mode to User Space. It does not matter which direction or which modes we are ~~swtiching~~ from, this is simply a general term. Crucial to mode switching is the <b>mode switch time</b> which is the time necessary to execute a system call instruction in user-mode, perform the kernel mode execution of the system call, and finally return the execution back to user-mode.[1]<br><br>		<b>Mode Switches</b> speak of moving from one medium to another. Specifically moving from the User Space mode to the Kernel mode or Kernel mode to User Space. It does not matter which direction or which modes we are switching from, this is simply a general term. Crucial to mode switching is the <b>mode switch time</b> which is the time necessary to execute a system call instruction in user-mode, perform the kernel mode execution of the system call, and finally return the execution back to user-mode.[1]<br><br>

	===Synchronous System Call===		===Synchronous System Call===

Tafatah: /* References: */

2010-12-02T18:28:25Z

References:

← Older revision		Revision as of 18:28, 2 December 2010
Line 190:		Line 190:
	[20] M. Brian Blake, <i>Coordinating Multiple Agents for Workflow-Oriented Process Orchestration</i>. Information Systems and e-Business Management Journal, Springer-Verlag, December 2003. [http://www.cs.georgetown.edu/~blakeb/pubs/blake_ISEB2003.pdf PDF]		[20] M. Brian Blake, <i>Coordinating Multiple Agents for Workflow-Oriented Process Orchestration</i>. Information Systems and e-Business Management Journal, Springer-Verlag, December 2003. [http://www.cs.georgetown.edu/~blakeb/pubs/blake_ISEB2003.pdf PDF]

	[21] DeveloperWorks, Kernel Command using Linux System Calls IBM,2010.[http://www.ibm.com/developerworks/linux/library/l-system-calls/ ]		[21] DeveloperWorks, Kernel Command using Linux System Calls IBM,2010.[http://www.ibm.com/developerworks/linux/library/l-system-calls/ HTML]

	[22] McCracken, Dave. <i>POSIX Threads and the Linux Kernel</i>, IBM Linux Technology Center, Austin, TX. In Proceedings of the Ottawa Linux Symposium, 2002. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.8887&rep=rep1&type=pdf#page=330 PDF]		[22] McCracken, Dave. <i>POSIX Threads and the Linux Kernel</i>, IBM Linux Technology Center, Austin, TX. In Proceedings of the Ottawa Linux Symposium, 2002. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.8887&rep=rep1&type=pdf#page=330 PDF]

Tafatah: /* References: */

2010-12-02T18:27:35Z

References:

← Older revision		Revision as of 18:27, 2 December 2010
Line 191:		Line 191:

	[21] DeveloperWorks, Kernel Command using Linux System Calls IBM,2010.[http://www.ibm.com/developerworks/linux/library/l-system-calls/ ]		[21] DeveloperWorks, Kernel Command using Linux System Calls IBM,2010.[http://www.ibm.com/developerworks/linux/library/l-system-calls/ ]

			[22] McCracken, Dave. <i>POSIX Threads and the Linux Kernel</i>, IBM Linux Technology Center, Austin, TX. In Proceedings of the Ottawa Linux Symposium, 2002. [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.2.8887&rep=rep1&type=pdf#page=330 PDF]