TPShare: A Time-Space Sharing Scheduling Abstraction For Shared Cloud .

1y ago
9 Views
2 Downloads
3.61 MB
14 Pages
Last View : 1d ago
Last Download : 2m ago
Upload by : Halle Mcleod
Transcription

TPShare: A Time-Space Sharing Scheduling Abstraction forShared Cloud via Vertical LabelsYuzhao Wang yuzhao w@hust.edu.cnHuazhong University of Science andTechnologyWuhan, Hubei, ChinaJunqing Yuyjqing@hust.edu.cnHuazhong University of Science andTechnologyWuhan, Hubei, ChinaLele Lill.li@siat.ac.cnShenzhen Institute of AdvancedTechnology (SIAT), CASShenzhen, Guangdong, ChinaZhibin Yuzb.yu@siat.ac.cnShenzhen Institute of AdvancedTechnology (SIAT), CASShenzhen, Guangdong, ChinaABSTRACTCurrent shared cloud operating systems (cloud OS) such as Mesosand YARN are based on the "de facto" two-horizontal-layer cloudplatform architecture, which decouples cloud application frameworks (e.g., Apache Spark) from the underlying resource management infrastructure. Each layer normally has its own task or resource allocation scheduler, based on either time-sharing or spacesharing. As such, the schedulers in different layers are unavoidablydisconnected, — not aware of each other, which highly likely leads toresource (e.g.,CPU) wastes. Moreover, the tail latency may even beharmed due to the performance interference on shared resources.This paper takes the first step to establish the critical missing connection between the horizontal layers. We propose TPShare, a timespace sharing scheduling abstraction, using a simple but efficientvertical label mechanism to coordinate the time- or space-sharingschedulers in different layers. The vertical labels are bidirectional(i.e., up and down) message carriers which convey necessary information across two layers and are kept as small as possible. Theschedulers in different layers can thus take actions according tothe label messages to reduce resource wastes and improve tail latency. Moreover, the labels can be defined to support different cloudapplication frameworks.We implement the label mechanism in Mesos and two popularcloud application frameworks (Apache Spark and Flink) to studythe effectiveness of the time-space sharing scheduling abstraction.The label messages of TPShare reduce resource waste and performance interference due to independent time-sharing or spacesharing scheduling of different layers by enabling 1) on-demandfine-grained resource offering, 2) load-aware resource filtering, and YuzhaoWang is an intern at SIAT.Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from permissions@acm.org.ISCA ’19, June 22–26, 2019, Phoenix, AZ 2019 Copyright held by the owner/author(s). Publication rights licensed to ACM.ACM ISBN 978-1-4503-9999-9/18/06. . . 15.00https://doi.org/10.1145/1122445.1122456You Wuyouwu@usc.eduUniversity of Southern CaliforniaLos Angeles, California, USAXuehai Qianxuehai.qian@usc.eduUniversity of Southern CaliforniaLos Angeles, California, USA3) resource demand scaling with global view, eventually improvingperformance and tail latency.We co-locate 13 Spark batch and 4 Flink latency-sensitive programs on a 8-node cluster managed by TPShare to evaluate thespeedup, CPU and memory utilization, and tail latency. The resultsshow that TPShare accelerates the Spark programs significantlywith even lower CPU and memory utilization compared to Mesos.With higher resource utilization, the throughput of TPShare is drastically larger than that of Mesos. For the Flink programs, TPShareimproves the 99th tail latency by 48% on average and up to 120%.CCS CONCEPTS Computer systems organization Cloud Computing; Performance; Resource Management.KEYWORDSCloud Computing, Task Scheduling, Resource ManagementACM Reference Format:Yuzhao Wang, Lele Li, You Wu, Junqing Yu, Zhibin Yu, and Xuehai Qian. 2019.TPShare: A Time-Space Sharing Scheduling Abstraction for Shared Cloudvia Vertical Labels. In ISCA ’19: ACM Symposium on Computer Architecture,June 22–26, 2019, Phoenix, AZ. ACM, New York, NY, USA, 14 pages. ONTraditional cloud application frameworks such as Hadoop 1.0 [47]tightly couple a specific programming model (e.g., MapReduce) andits implementation framework with the underlying resource management infrastructure. This design puts the burden of resourcemanagement on cloud application developers, causing endless scalability concerns for task schedulers [49]. To address this drawback,current cloud operating systems (cloud OS) such as Mesos [22] andYARN [49] decouple application frameworks (e.g., Apache Spark)from the underlying resource management infrastructure, — forming two abstraction layers. Such separation of concern significantlyrelieves the burden of resource management from application developers, and facilitates better scalability of cloud task schedulers. Asa result, Mesos and YARN have been widely used in internet companies such as Twitter and Yahoo!, and such two-horizontal-layerarchitecture has become the "de facto" standard in shared cloud.

ISCA ’19, June 22–26, 2019, Phoenix, AZYuzhao Wang, Lele Li, You Wu, Junqing Yu, Zhibin Yu, and Xuehai Qian.In this two-layer architecture, each layer has its own scheduler toschedule tasks or allocate resources within that layer. For example,in a Mesos based platform, the scheduling policy at the cloud OSlayer is dominant resource fairing (DRF) [17], and the schedulingpolicy in the application framework layer depends on the specificframework. For instance, Apache Spark [44, 57] employs delayedscheduling [56] while Apache Flink [1, 14] uses eager scheduling [2,40]. In general, these scheduling policies belong to two categories:time-sharing and space-sharing. If a scheduler schedules multipletasks to concurrently run on shared virtual or physical resources butonly one task runs on the shared resources at any certain moment(time-slicing), we call it time-sharing scheduling. If a schedulerschedules multiple tasks to concurrently run on logically sharedphysical resources but the resources are physically divided intomultiple zones (space-slicing) and different tasks run in differentzones without any time-sharing, we define it as space-sharing. Assuch, delayed scheduling belongs to time-sharing while DRF andeager scheduling can be considered as space-sharing.Despite the advantage of the separation concerns, a natural pitfall of such two-layer architecture is that, the schedulers in differentlayers are unaware of each other and independently schedule tasksaccording to their own policy. In essence, the time- or space-sharingschedulers of different layers are disconnected without any coordination. This may result in significant resource wastes at spacedimension, and severe performance degradation at time dimension.This paper proposes TPShare, a time-space sharing schedulingabstraction as the first step to establish the critical missing connectionbetween horizontal layers. The key idea is to use vertical label, asimple but efficient mechanism, to enable the coordination of thetime- or space-sharing schedulers from different horizontal layers.The vertical labels are bidirectional (i.e., up and down) messagecarriers which convey necessary information across layers andare kept as small as possible. The schedulers in different layersleverage the label messages to take proper actions, if necessary, toreduce space/time wastes, and finally improve performance and taillatency. Note that TPShare is not a new stand-alone task schedulingalgorithm or policy. Instead, it is a scheduling abstraction withnecessary interfaces to connect and coordinate the schedulers indifferent layers when necessary.We name the coordinated time- or space-sharing scheduling astime-space sharing scheduling. Although Hawk [10], Mercury [26],and Eagle [9] all employ a mixed scheduling policy of time-sharingand space-sharing, they do not consider to coordinate time- orspace-sharing scheduling among different horizontal layers. Instead,they simply employ space-sharing for short jobs and time-sharingfor long ones in the same horizontal layer.Distinct from prior works, our time-space sharing schedulingabstraction allows developers to define the direction and content ofthe vertical labels. Specifically, the vertical label can be bidirectional,which means that the label message can be passed from a lower layerto a upper layer and vice versa. The content of a label message canbe defined to support different application frameworks, e.g., ApacheSpark [44, 57] and Flink [14]. As a result, the time-space sharingscheduling abstraction is flexible for different situations. Althoughcurrent cloud OS and application frameworks do not support thevertical label mechanism, we envision it to be mandatory for thenext generation of shared cloud.To demonstrate the effectiveness of time-space sharing scheduling abstraction, we implement the vertical label mechanism onApache Mesos and two popular could application frameworks:Apache Spark and Apache Flink. We leverage the label mechanismto realize three techniques of TPShare to coordinate the schedulers from the two layers: on-demand fine-grained resource offering(RO), load-aware resource filtering (RF), and resource demand scalingwith global view (RS). The three novel techniques enable resourcemanagement policies not possible in current cloud OSs. For example, Mesos packages all available resources of a slave server asa coarse-grained resource offer, and provides it to an applicationframework each time sequentially because Mesos does not knowthe amount of resources required by the application. In contrast,TPShare can leverage RO to divide the coarse-grained resource offerinto multiple fine-grained resource offers according to the demandsof corresponding applications, and then provide the offers to theapplications in parallel. Moreover, TPShare employs RF to filter outservers whose load is already high when providing resource offersto applications, — not supported in Mesos. Finally, the RS techniquetakes cluster-wide resource status into consideration, and guidesthe application to adjust their resource demand to favour performance. As a result, RO and RS reduce resource wastes, whereas RFdecreases performance interference.To evaluate the performance of TPShare, we employ an 8-nodecluster and co-locate 13 Spark batch and 4 Flink latency-sensitiveprograms on it. Compared to Mesos, the results show that TPSharecan accelerate the Spark programs significantly with even lowerCPU and memory utilization. It effectively makes running moreprograms on TPShare with comparable performance of Mesos possible. In other words, the results show that, when the resourceutilization is increased, the throughput of TPShare is dramaticallyhigher than that of Mesos. For Flink programs, TPShare improvesthe 99th percentile tail latency by 48% on average and up to 120%over Mesos.To evaluate the adaptivity (i.e., whether its effectiveness dependson certain cluster) of TPShare, we use a different 4-node clusterand construct a different scenario: co-locate a Python program withinfinite loops as a severe CPU disturber with 13 Spark programs.The results show that TPShare can still improve the CPU utilizationby 3% on average and up to 6% compared to Mesos. Accordingly,TPShare accelerates the Spark programs by 1.37 on average andup to 9.3 . Moreover, the results show that TPShare can improvemore CPU utilization and achieve more speedups with larger inputdatasets. We also co-run a Spark streaming program with the CPUdisturber to evaluate the tail latency. The results show that TPShareimproves the 99th percentile tail latency by 190%.2BACKGROUND AND MOTIVATIONIn this section, we first take the Mesos-based cloud platform asan example to describe the two-layer cloud architecture. We thendescribe our motivation.2.1Two Layers and Their Schedulers in MesosApache Mesos is a cloud OS built by using the same principles as theLinux kernel but at a different level of abstraction [22]. The goal ofMesos is to share commodity clusters between multiple diverse application frameworks such as Spark and Hadoop to improve cluster

83.4 45.716199.398 20.99365TPShare: A Time-Space Sharing Scheduling Abstraction for Shared Cloud via Vertical LabelsApplication FrameworksMesosScheduler: DRFCloud Operating SystemServer 1.Server 2Two layersServer icluster. Server nCPU 32 0CPU 30 2120100806040200CPU 32 0CPU 30 2latencs(s)SparkScheduler: DLS120100806040200maxm minst p50p75p95p98p99p9 ApplicationsISCA ’19, June 22–26, 2019, Phoenix, AZlatency(s)Spark 419 35.84703 33.13059 32.74539(a) repartitionmaxmeanminstd p50p75p95p98p99p9 CPU 30 2(b) wordcountFigure 2: Latency with different scheduling strategies. pXXFigure 1: The two-layer architecture of Mesos clusters. DLSrepresents xx percentile tail latency. For example, p99Delayed Scheduling, DRF-Dominant Resource Fairness.means 99th percentile tail latency.wordcountCPU 32 0 indicates thestrategy casemax wheremeanminstddevp50p95pro- p98all32coresofaserverareusedp75by the 31utilization. Figure 1 illustrates the two-layer architecture of MesosCPU 32 0 grams107.59549.5370516.8928.4364738.2665.878100.67 104.712andnocoresoftheotherserverareused.CPU 30 2based cloud platforms. As we can see, besides the applications, theCPU 30 269.015 33.9022111.594 ere2coresofaserverareusedbytwo system layers are cloud OS and application framework. Therepartition or wordcount and the 30 cores of the other servercloud OS is Mesos but it can be YARN or others. The applicationare used by the 30 disturbers.frameworks can be Apache Spark or other frameworks such asTime-spaceof the other server is used. In contrast, the program repartitionTwo-layercloud and labelsApache Flink. In this paper, we considerSparkFlink. sharingarchitecture(orwordcount) may also run on the two cores of one server andschedulingGenerally, each of the two system layers has its own task schedthe30 CPU disturbers run on the 30 cores of the other server inScheduleruling policy or algorithm. As Figure 1Applicationsshows, at the cloud OSlayer,othertimes, denoted by CPU 30 2. The tail latencies in the case ofalthough Mesos pushes task scheduling to application frameworksApplication FrameworksSchedulerCPU 32 0for repartition and wordcount are longer than those insuch as Spark, it still has its own resource allocation policy, — domthe case of CPU 30 2 by 34.6% and 47.5% on average, respectively.inant resource fairness (DRF), whichcanbeconsideredasspaceCloud Operating SystemSchedulerThis indicates scheduling tasks to different server/cores leads tosharing scheduling. At the application framework layer, the tasksignificantly tail latency variance. What’s worse, the case CPU 32 0scheduling algorithm is framework specific. For example, Apacheor CPU 30 2 randomly takes place when we co-run the programs onSpark employs a time-sharing schedulingalgorithm,delayschedulServer 1 Server2 . Serveri .Server nMesos. This further indicates that the tail latency is unpredictableing (DLS) [56]; while Apache Flink uses the eagerschedulingalgoclusterwhenprograms run on shared resources, which is confirmed byrithm [2, 40] which can be considered as a dynamic space-sharingpreviousstudies on other cloud platforms [58, 59, 61].scheduling algorithm. While these schedulers from different layersOneimportantreason for this issue is that the scheduler frommay work well for their own corresponding layer, they are unawarethe application framework layer (the Spark) and the one from theof each other.cloud OS layer (the Mesos) are mutual unaware of each other. Atthe application layer, for the latency-critical Spark program reparti2.2 Disconnected Scheduling between Layerstion, Spark employs DLS to send resource requests to Mesos. TheThe problem of disconnected scheduling between horizontal layersdisturbers request resource from Mesos according to their startingis caused by the mutual unawareness between schedulers fromorder. At the cloud OS layer, Mesos uses DRF to offer resources fordifferent layers, which may lead to significant time and space wastesthe applications in the above layer. However, Mesos does not knowin the presence of performance interference on shared resources.the fact that repartition is latency-critical and in turn just offers itTo understand how the disconnected scheduling affects throughputenough resources but does not consider where the resources areand tail latency, we design the following experiments.and whether the resources can satisfy the latency-critical requireWe employ a 2-node cluster with 32 cores in each node andment. This leads to the behavior that the long or short latency ofuse Mesos to manage the cluster. On top of Mesos, we co-run athe program repartition takes place randomly, being unpredictable.Spark streaming program, repartition and 30 Python programs withAlthough this motivation example is an artificial case by coeach containing an infinite loop. repartition is latency-critical andlocating a latency-critical or a batch program with an artificialis vulnerable to interference. Each Python program with an infiniteCPU disturber, it represents the principle of co-locating normalloop consumes up one CPU core and can be used to severely disturbprograms. We confirm this by running repartition on the clusterthe co-located program repartition. The Python program is calledfirst, then co-running wordcount on the same cluster, and vice versa.as a CPU disturber. Moreover, we allocate two cores for repartitionWe observe that the unpredictable performance issue still holds.and start 30 disturbers to make them consume 30 cores in total. WeMoreover, the latency of repartition when it co-runs with wordcountrun these 31 programs on the clusters several times and observe theon the same server is significantly longer than that it runs on athroughput and tail latency. In addition, we also co-run wordcountsingle server separately. Note that the total CPU consumption andwhich is a batch-processing program and 30 disturbers to validatememory consumption of these two programs are significantly lessour observations.than the total amount of CPU and memory resources of a singleFigure 2 (a) shows the results for repartition and Figure 2 (b)server. This indicates that artificial and normal programs both sufferfor wordcount. As we can see, some times the program repartitionfrom unpredictable performance on a Mesos cluster.(or wordcount) and the 30 disturbers run on all the 32 cores of the2.3 The Need for a Vertical Label Mechanismsame server and all the cores of the other server in the clusterare idle. We use CPU 32 0 to denote this case where ’32’ indicatesOne may think that we can solve the aforementioned disconnectedall the 32 cores of a server are used and ’0’ indicates that no corescheduling issue by using one scheduler to schedule the tasks or

ISCA ’19, June 22–26, 2019, Phoenix, AZTwo-layer cloudarchitecturelabelsYuzhao Wang, Lele Li, You Wu, Junqing Yu, Zhibin Yu, and Xuehai lerApplication FrameworksSchedulerCloud Operating SystemSchedulerServer 1Server 2. Server i . Server nclusterFigure 3: Time-space sharing scheduling abstraction.allocate resources of the two horizontal layers at the same time,which we call vertical-global scheduling. However, vertical-globalscheduling does not work well because it needs to tightly couplethe two horizontal layers together, which is exactly what Hadoop1.0 did before. This approach has at least two shortcomings: imposing resource management burden on application developers,and poor scalability of the scheduler. To overcome these limitations, we propose a vertical label mechanism that can still keepthe two horizontal layers separated and provides label messagesto convey necessary but yet small messages across the layers tocoordinate the schedulers from different layers and meet variousrequirements of different layers. In the next section, we describe ourtime-space scheduling abstraction with a vertical label mechanismfor shared cloud. We argue that the vertical label mechanism shouldbe mandatory for the next generation of shared cloud platforms.3TIME-SPACE SHARING SCHEDULINGIn this section, we describe our time-space sharing scheduling abstraction with the vertical label mechanism.3.1OverviewMost of current scheduling policies (algorithms) of cloud systemscan be classified into either time-sharing [4, 12, 19, 41, 50] or spacesharing [2, 35] scheduling according to our definition but not both.This makes it extremely difficult to improve resource utilizationand tail latency simultaneously in shared cloud even with manydifferent stand-alone time-sharing or space-sharing scheduling algorithms, policies, and strategies. In fact, improving performance(e.g., execution time or throughput), resource utilization, and taillatency at the same time is indeed a dilemma based on currentscheduling techniques for shared cloud. We therefore argue thatthe time-sharing or space-sharing schedulers from different layersin a system should work cooperatively. This leads to the time-spacesharing scheduling.Figure 3 shows an overview of our time-space scheduling abstraction. The key idea is to leverage a label mechanism to conveynecessary information across the two layers of a cloud platform.The time- or space-sharing schedulers of different layers can usesuch information to take the most suitable actions if necessaryto coordinate each other. With the cross-layer collaboration, theperformance, resource utilization, and tail latency can be improvedat the same time.As shown in Figure 3, we design the label as a bidirectionalchannel which can convey information from the lower cloudOSlayer to the upper application layer, and vice versa. Note that we donot consider the application scheduler layer in this work becausethe Spark or Flink programs themselves do not have schedulers.The tasks of them are scheduled by the schedulers in the applicationframeworks (e.g., Spark or Flink). By doing so, the schedulers fromthe lower cloudOS layer can adjust scheduling actions accordingto the requirements from the upper application framework layerwhile the ones from the upper layer can schedule tasks based onthe status (e.g., resources are busy or idle) of the lower layer. Ourlabel mechanism not only allows the bidirectional label to conveymessages in one direction at a time but even allows such messagesto be exchanged in both directions between the two horizontallayers at the same time when scheduling is performed.In summary, the label mechanism enables our time-space sharingscheduling abstraction to be flexibly adapted to different situationsand to orderly coordinate the schedulers from two horizontal layers of a shared cloud. Although some studies such as Hawk [10],Mercury [26], and Eagle [9], apply both time-sharing and spacesharing scheduling in a system, they simply employ time-sharingscheduling for long tasks and use space-sharing for short tasks, andthese schedulers work independently.3.2Label MessageThis section discuss the details of label messages and how they aregenerated, as well as how to act on them.3.2.1 What are label messages? We propose three kinds of labelmessages to satisfy possible requirements for shared cloud: temporal, spatial, and temporal-spatial label messages. The temporallabel messages are related to time and can be: the deadline of abatch job, the tolerable latency of a web-search-like operation, theresponse time for interactive applications, the priority of a task,and so on. Note that we use the term "deadline" only for batchjobs/tasks. In addition, "latency" is different from "response time"in our terminology because "latency" is used to represent the timebetween the moment a user starts a request and the one he/she getsthe results, while "response time" refers to the time between themoment a user starts a request and that the system responses.The spatial label messages are related to space (e.g., computingresources). Examples of spatial label messages include the numberof CPU cores, the size of memories and disks, memory, disk I/O,and network bandwidth, and so on. In addition, the label messagecan also be a bundle of resources such as 2 CPU cores, 2GB mem or the amount of a kind (or bundle) of resources such as CPU.The temporal-spatial label messages are used to specify the required performance which is affected by both temporal and spatialfactors. This kind of label messages include query per seconds(QPS), the maximum or minimum number of tasks needed to beprocessed on a given cluster in a specified amount of time, the ratioof successfully processed tasks in a given interval of time on a givencluster, and so on.3.2.2 How to generate label messages? We propose two ways togenerate the label messages: manual setting and optimal setting.Manual setting refers that the label messages are set by users, developers, or system administrators manually. Since some spatiallabel messages such as the number of CPU cores are already inthe configuration file of a system such as Spark, we can add thelabel messages as configuration parameters and set them manually

TPShare: A Time-Space Sharing Scheduling Abstraction for Shared Cloud via Vertical Labelsin the configuration file. Subsequently, the label messages can begenerated automatically according to the configuration file aftera program is initialized. Of course, the label messages can also beset in the source codes of a system or by command lines. However,manually setting the temporal, temporal-spatial, and spatial labelmessages has difficulties to some extent. In particular, manuallysetting spatial label messages can not achieve optimal performanceor other targets although it works correctly. Optimal setting istherefore proposed to generate "ideal" label messages for a certaintarget. For example, a Spark task may need 3 cores for optimal performance but 1 or 2 cores may be set by manual setting. However,optimally setting all kinds of label messages is extremely difficult.We therefore discuss how to generate temporal and temporal-spatiallabel messages by manual setting and how to generate spatial labelmessages by optimal setting.The temporal label messages can be provided by end users oradministrators of cloud computing platforms because it is not difficult for a user to specify the time he/she wants to complete his/hersubmitted jobs or tasks. For example, users can specify the deadlines of their batch processing jobs based on their experience andtherefore indicate the deadlines as label messages. Another exampleis that users can specify the priorities of their jobs or specify theirjobs as latency-critical ones which have higher priority than batchjobs. As for setting the temporal-spatial label messages, it may bedifficult for end users but it is still doable for the administratorsof a shared cloud because they are familiar with the performancesuch as QPS of the cloud platform they manage. We therefore propose to let administrators set the temporal-spatial label messagesif necessary. Note that the temporal or temporal-spatial label messages are related to users/administrators’ requirements which maybe significantly different for the same type of jobs. It is difficultto satisfy everyone’s requirements because everyone expects theshortest latency, closest deadlines, and others of their jobs. Weleave this optimization problem as a future work because this workproposes a scheduling abstraction which expects many differentimplementations and optimizations.Optimally setting a spatial label message might be difficult forboth end users and administrators because it is not easy to knowhow much resource is exactly needed by a task. Currently, somespatial label messages such as the number of cores and the size ofmemory needed by a task are also configuration parameters of asystem such as Spark. In practice, developers either set the valuesof these parameters manually based on experience or just use theirdefault values. However, although this approach works, the values are not "ideal" because they are affected by not only programcharacteristics but also input data. One set of default values aretherefore not "ideal" for different programs and input datasets. Manually setting the spatial label messages for many program and inputpairs, if possible, would be very time-consuming. To address thisissue, we propose to leverage machine learning techniques to learnthe resource demand of a task for a given shared cloud becauseresearchers have employed suitable machine learning algorithmsto successfully optimize the configuration parameters of ApacheSpark programs and achieved significantly high performance [55].Therefore, using machine learning techniques to optimally set spatial label messages for a given program and input pair on a givenshared cloud is a viable approach.ISCA ’19, June 22–26, 2019, Phoenix, AZApache SparkApache Flinktask 1 task 2task 1 task 2SchedulerInterface forMesosSchedulerInterface forMesos task1,s1,2cpu.1GB, task2,s1,1cpu,2GB,. 3 s1,4cpu.4GB,. 2Allocator s1,4cpu.4GB,. 14 Spark,task1,2cpu.1GB, Spark,task2,1cpu,2GB,. Mesos Slave 1ExecutorTaskTaskMesosMasterAgentMesos Slave 2ExecutorTaskTaskAgentFigure 4: Mesos architecture with Apache Spark.3.2.3 How to act on label messages? The vertical label mechanismis proposed to coordinate different schedulers from different layersif necessary. It does not change the original scheduling algorithmsor policies. Instead, the system takes proper actions according to thelabel messages on top of the original schedulers. We now discuss

We name the coordinated time- or space-sharing scheduling as time-space sharing scheduling. Although Hawk [10], Mercury [26], and Eagle [9] all employ a mixed scheduling policy of time-sharing and space-sharing, they do not consider to coordinate time- or space-sharing scheduling among differenthorizontallayers. Instead, they simply employ .

Related Documents:

sharing sectors, including peer-to-peer sharing, online staffing, car sharing, sharing the accommodation and music streaming will make more than half of the total worldwide income (PwC, 2015). The global revenue of sharing economy will grow to US 335 billion by the end

With simple file sharing, the act of enabling file sharing on a folder and specifying the type of access is simplified to the following choices: Whether to enable sharing for the folder The name of the share Whether to allow network users to change files in the folder The Sharing tab for simple file sharing is shown in the following figure.

KT08/I Time-Sharing Option, DEC-8I-H-8NA-D ix . 1.1 GENERAL DESCRIPTION CHAPTER 1 INTRODUCTION TSS/8 (Time-Sharing System for the PDP-8/1 and -8 Computers) is a general-purpose, time-sharing system offering up to 16 users (24 in certain applications) a comprehensive library of System Programs. These programs

SDS decided .to make the Berkeley Time-Sharing Soft ware System available to the market. This decision led to the development, by SDS, of the SDS 940 Time Sharing Computer System. The result is a set of SDS produced equipment that is fully compatible with the Berkeley Time-Sharing Software System. In particular,

Time-sharing was in the air in 1961. John McCarthy had been thinking about it since 1955 and in 1959 wrote a memo proposing a time-sharing system for the IBM 709 computer at MIT. Fernando Corbató and two of his MIT Computer Center staff members, Robert Daley and Marjorie Merwin, starting working on the design of the Compatible Time Sharing

the Spectra 70 Time Sharing Sys tem are scheduled for first delivery during the third quarter of 1968. The 70/46 marks RCA's entry into the time-sharing' computer market, joining such competition as the GE-645, IBM System 3601 Model 67, and SDS Sigma 7 com puter systems. Howev r, R A has' designed its time-sharing system

The Time-Sharing System which uses the GE-225 computer is called the GE-255; the Time-Sharing System using the GE-235 computer is called the GE-265. This reference manual briefly describes the hardware that comprises the GE-200 Series Time Sharing System (GE-255 or 265) and the communications eqUipment that supports it. The manual

according to ASTM F 2213-06, ASTM F 2052-14 and ASTM F2119-07 Non-clinical testing of worst case scenario in a 3 T MRI system did not reveal any relevant torque or displace- ment of the construct for an experimentally measured local spatial gradient of the magnetic field of 5.4 T/m. The largest image artifact extended approximately 35 mm from the construct when scanned using the Gradient Echo .