X-ARCC - Revision history

imported>Shofmeyr at 22:33, May 13, 2016

2016-05-13T22:33:50Z

← Older revision		Revision as of 22:33, May 13, 2016
Line 4:		Line 4:
	\| website = http://tessellation.cs.berkeley.edu		\| website = http://tessellation.cs.berkeley.edu
	\| imagecaption =		\| imagecaption =
	\| download = https://bitbucket.org/berkeleylab/~~CRD~~-X-~~ARCC~~		\| download = https://bitbucket.org/berkeleylab/crd-x-arcc
	\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]		\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]
	\| pi = Steven Hofmeyr (LBNL)		\| pi = Steven Hofmeyr (LBNL)

imported>Shofmeyr at 22:33, May 13, 2016

2016-05-13T22:33:02Z

← Older revision		Revision as of 22:33, May 13, 2016
Line 4:		Line 4:
	\| website = http://tessellation.cs.berkeley.edu		\| website = http://tessellation.cs.berkeley.edu
	\| imagecaption =		\| imagecaption =
	\| download = https://bitbucket.org/berkeleylab/X-ARCC		\| download = https://bitbucket.org/berkeleylab/CRD-X-ARCC
	\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]		\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]
	\| pi = Steven Hofmeyr (LBNL)		\| pi = Steven Hofmeyr (LBNL)

imported>Shofmeyr at 05:47, May 13, 2016

2016-05-13T05:47:36Z

← Older revision		Revision as of 05:47, May 13, 2016
Line 4:		Line 4:
	\| website = http://tessellation.cs.berkeley.edu		\| website = http://tessellation.cs.berkeley.edu
	\| imagecaption =		\| imagecaption =
	\| download =		\| download = https://bitbucket.org/berkeleylab/X-ARCC
	\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]		\| team-members = [http://www.berkeley.edu/ UC Berkeley], [http://www.lbl.gov/ LBNL]
	\| pi = Steven Hofmeyr (LBNL)		\| pi = Steven Hofmeyr (LBNL)

imported>Shofmeyr at 03:47, January 14, 2014

2014-01-14T03:47:34Z

← Older revision		Revision as of 03:47, January 14, 2014
Line 1:		Line 1:
	{{~~Infobox3~~ project		{{Infobox project
	\| title = X-ARCC: Exascale Adaptive Resource Centric Computing with Tesselation		\| title = X-ARCC: Exascale Adaptive Resource Centric Computing with Tesselation
	\| image = [[File:xarcc.png\|320x300px]]		\| image = [[File:xarcc.png\|320x300px]]

imported>Shofmeyr: /* System Services for Resilience */

2014-01-09T05:18:00Z

System Services for Resilience

← Older revision		Revision as of 05:18, January 9, 2014
Line 402:		Line 402:
	clock synchronization algorithms as needed. Also in the first year we will begin		clock synchronization algorithms as needed. Also in the first year we will begin
	the development of the QoS-guaranteed services, with a QoS-aware service		the development of the QoS-guaranteed services, with a QoS-aware service
	framework by Q4. ~~<!--Q2, and the Block Service by Q4-->~~ Finally, we will begin to port		framework by Q4. Finally, we will begin to port
	GASNet: specifically, we will aim to get GASNet functional with the SMP conduit,		GASNet: specifically, we will aim to get GASNet functional with the SMP conduit,
	by Q4.		by Q4.

	'''Year 2''': During the second year of the project, we will continue		'''Year 2''': During the second year of the project, we will continue
	work on the services, with the implementation of the Block Service by Q2 and the Object Store Service by Q4. ~~<!--Object Store Service by Q3~~		work on the services, with the implementation of the Block Service by Q2 and the Object Store Service by Q4. Furthermore, we will use the Block Store service to develop advanced memory management features,
	~~and Logging Service by Q4-->~~ Furthermore, we will use the Block Store service to develop advanced memory management features,
	primarily user-level paging by Q4. Another		primarily user-level paging by Q4. Another
	objective of year two is to have the UPC versions of the Co-design proxy apps		objective of year two is to have the UPC versions of the Co-design proxy apps

imported>Shofmeyr at 05:17, January 9, 2014

2014-01-09T05:17:05Z

← Older revision		Revision as of 05:17, January 9, 2014
Line 387:		Line 387:
	but also to the I/O subsystem.		but also to the I/O subsystem.

			<!--
	== Timetable ==		== Timetable ==

Line 424:		Line 425:
	Q4. We will conclude the final year with a software release to the exascale		Q4. We will conclude the final year with a software release to the exascale
	community.		community.

			-->

	== Team Members ==		== Team Members ==

imported>Shofmeyr: /* System Services for Resilience */

2014-01-09T05:13:44Z

System Services for Resilience

← Older revision		Revision as of 05:13, January 9, 2014
Line 370:		Line 370:
	To date we have developed two QoS-aware system services: a network		To date we have developed two QoS-aware system services: a network
	service and a GUI service. We intend to implement a framework that will make it		service and a GUI service. We intend to implement a framework that will make it
	easy to develop QoS-aware services, which we will use for developing ~~three~~		easy to develop QoS-aware services, which we will use for developing two
	additional services: a Block Service, an Object		additional services: a Block Service and an Object Store Service:
	Store ~~Service, and a Logging~~ Service:

	* The ''Block Service'' will provide block-level operations with additional QoS guarantees to applications or other services. It is an essential basis for advanced memory management, providing swap pager support to individual cells.		* The ''Block Service'' will provide block-level operations with additional QoS guarantees to applications or other services. It is an essential basis for advanced memory management, providing swap pager support to individual cells.

	* The ''Object Store Service'' (OSS) will provide persistent storage through a simple interface that will enable applications to put (and retrieve) variable sized objects in a flat namespace. QoS guarantees from the OSS will include such parameters as guaranteed number of cached pages or read and/or commit bandwidth. This service will extend the traditional on-disk inode structure into a generic persistent local store available to clients (applications or services). Although a POSIX-like Filesystem API will be available for the Object Store Service, clients will also be able to manipulate stored objects outside of the POSIX APIs, to reduce the overhead associated with maintaining POSIX-required metadata.		* The ''Object Store Service'' (OSS) will provide persistent storage through a simple interface that will enable applications to put (and retrieve) variable sized objects in a flat namespace. QoS guarantees from the OSS will include such parameters as guaranteed number of cached pages or read and/or commit bandwidth. This service will extend the traditional on-disk inode structure into a generic persistent local store available to clients (applications or services). Although a POSIX-like Filesystem API will be available for the Object Store Service, clients will also be able to manipulate stored objects outside of the POSIX APIs, to reduce the overhead associated with maintaining POSIX-required metadata.

	* The ''Logging Service'' will provide durability for journalled metadata operations on behalf of filesystem-like operations, much like the journaling block device (JBD) used by the ext4 filesystem. However, the Logging Service will differ from JBD in several key respects: It will perform both forwards (redo) and backwards (undo) recovery, and it will not be limited to physical full-page updates. Also, the logging service will be open; multiple clients, not just the filesystem, will be able to use log services, i.e. the logging service can be used directly by applications to implement application-specific resilience.

	The implementations of these services are sufficient to investigate a wide		The implementations of these services are sufficient to investigate a wide

imported>Shofmeyr: /* Overview */

2014-01-09T05:12:21Z

Overview

← Older revision		Revision as of 05:12, January 9, 2014
Line 16:		Line 16:
	Tessellation:		Tessellation:

	* What OS support is needed for new global address space programming models and task-based parallel programming models? To explore this, we are porting UPC ~~and Habanero~~ to run on multinode Tessellation, using GASNet as the underlying communication layer. Our test-cases for ~~these runtimes~~ on Tessellation are a subset of the Co-design proxy apps, which we use as representatives of potential exascale applications.		* What OS support is needed for new global address space programming models and task-based parallel programming models? To explore this, we are porting UPC to run on multinode Tessellation, using GASNet as the underlying communication layer. Our test-cases for this runtime on Tessellation are a subset of the Co-design proxy apps, which we use as representatives of potential exascale applications.
	* How should the OS support advanced memory management, including mechanisms for user-level paging, locality-aware memory allocation and multicell shared memory?		* How should the OS support advanced memory management, including mechanisms for user-level paging, locality-aware memory allocation and multicell shared memory?
	* How do we extend hierarchical adaptive resource allocation and control across multiple nodes~~, including heterogeneous nodes such as the Intel Mic~~?		* How do we extend hierarchical adaptive resource allocation and control across multiple nodes?
	* How should the OS manage the trade-off between power and performance optimizations? Will the Tessellation approach of treating both power and other resources (cores, memory) as first class citizens within the adaptive loop be adequate?		* How should the OS manage the trade-off between power and performance optimizations? Will the Tessellation approach of treating both power and other resources (cores, memory) as first class citizens within the adaptive loop be adequate?
	* What OS abstractions are needed for the durable QoS-guaranteed storage that is essential to resilience?		* What OS abstractions are needed for the durable QoS-guaranteed storage that is essential to resilience?

imported>Shofmeyr: /* Timetable */

2014-01-09T05:11:17Z

Timetable

← Older revision		Revision as of 05:11, January 9, 2014
Line 413:		Line 413:
	primarily user-level paging by Q4. Another		primarily user-level paging by Q4. Another
	objective of year two is to have the UPC versions of the Co-design proxy apps		objective of year two is to have the UPC versions of the Co-design proxy apps
	running by the end of the year (Q4). This will require porting the UPC~~/Habanero~~		running by the end of the year (Q4). This will require porting the UPC
	~~runtimes~~ (by Q2/Q3), which will depend on the previous port of GASNet. To enable		runtime (by Q2/Q3), which will depend on the previous port of GASNet. To enable
	multinode support, we intend to port the GASNet RDMA conduit by Q4.		multinode support, we intend to port the GASNet RDMA conduit by Q4.

imported>Shofmeyr: /* Support for New Programming Models and Multicomponent Applications */

2014-01-09T05:10:39Z

Support for New Programming Models and Multicomponent Applications

← Older revision		Revision as of 05:10, January 9, 2014
Line 234:		Line 234:
	sophisticated, multicomponent applications. To enable multinode, large scale		sophisticated, multicomponent applications. To enable multinode, large scale
	applications, we propose first porting GASNet as a communication layer, and then porting UPC for PGAS		applications, we propose first porting GASNet as a communication layer, and then porting UPC for PGAS
	~~models and Habanero for dynamic tasking and work-stealing~~
	models. We will focus on these frameworks because of time and budget		models. We will focus on these frameworks because of time and budget
	constraints, and because of our close relationship with the UPC and DEGAS		constraints, and because of our close relationship with the UPC and DEGAS
	projects. ~~Currently, the DEGAS team is moving towards an integrated UPC/Habanero~~		projects. . Of particular interest is what OS-specific support and
	~~runtime; depending on the timing, we may port the combined runtime, rather than~~
	~~separate components~~. Of particular interest is what OS-specific support and
	mechanisms may be needed for frameworks such as GASNet and UPC. This aspect of our research will allow us to explore one of the issues raised in the DOE Exascale OS/R		mechanisms may be needed for frameworks such as GASNet and UPC. This aspect of our research will allow us to explore one of the issues raised in the DOE Exascale OS/R
	report, namely:		report, namely: