What can we expect from Game Theory in Scheduling?

1. What can we expect from Game Theory in Scheduling? Denis Trystram (Grenoble University and INRIA) Collection of results of 3 papers with: Pierre-François Dutot (Grenoble University) Krzysztof Rzadca (Polish-Japanese computing school, Warsaw) Fanny Pascual (LIP6, Paris) Erik Saule (Grenoble university) may 23, 2008

2. Goal The evolution of high-performance execution platforms leads to physical or logical distributed entities (organizations) which have their own « local » rules, each organization is composed of multiple users that compete for the resources, and they aim to optimize their own objectives… Proposal: Construct a framework for studying such problems. Work partially supported by the Coregrid Network of Excellence of the EC.

3. content Basics in Scheduling (computational) models Multi-users scheduling (1 resource) Multi-users scheduling (m resources) Multi-organizations scheduling (1 objective) Multi-organizations with mixed objectives

4. Computational model Informally, a set of users have some (parallel) applications to execute on a (parallel) machine. The « machine » belongs or not to multiple organizations. The objectives of the users are not always the same.

5. Classical Scheduling Informal definition: given a set of n (independent) jobs and m processors, determine an allocation and a date for processing the tasks. ri pi Task i Ci i Objectives: based on completion times Cmax, Ci

6. Classical Scheduling (Cmax) Complexity results: the central problem is NP-hardit remains NP-hard for independent tasks Algorithms: List-scheduling [Graham 69]: 2-approximation LPT (largest first): 4/3-approximation m≥2

7. Classical Scheduling (Ci) Algorithm: SPT (shortest first): polynomial for any m

8. Multi-users optimization • Let us start by a simple case : several users compete for resources belonging to the same organization. • System centered problems (Cmax, load-balancing) • Users centered (minsum, maxstretch, flowtime) • Motivation:Take the diversity of users’ wishes/needs into account

9. A simple example Blue (4 tasks duration 3,4,4 and 5) has a program to compile (Cmax) Red (3 tasks duration 1,3 and 6) is running experiments (Ci) m=3 (machines) Global LPT schedule Cmax = 9 Ci = 6+8+9 = 23

10. A simple example Blue (4 tasks duration 3,4,4 and 5) has a program to compile (Cmax) Red (3 tasks duration 1,3 and 6) is running experiments (Ci) m=3 (machines) Global LPT schedule Cmax = 9 Ci = 6+8+9 = 23 SPT schedule for red Cmax = 8 Ci = 1+3+11 = 15

11. Description of the problem • Instance: k users, user u submit n(u) tasks, processing time of task i belonging to u: pi(u) • Completion time: Ci(u) • Each user can choose his-her objective among: • Cmax(u) = max (Ci(u)) or Ci(u) weighted or not • Multi-user scheduling problem: • MUSP(k’:Ci;k’’:Cmax) where k’+k’’=k

12. Complexity • [Agnetis et al. 2004], case m=1 • MUSP(2:Ci) is NP-hard in the ordinary sense • MUSP(2:Cmax) and MUSP(1:Ci;1:Cmax) are polynomial • Thus, on m machines, all variants of this problem are NP-hard • We are looking for approximation (multi-objective)

13. [Baker et al. 2003] (m=1) Linear aggregation: optimize Cmax + Ci User2: Ci User1: Cmax 1. Merge the tasks of user 1 2. Global SPT

14. [Baker et al. 2003] (m=1) Linear aggregation: optimize Cmax + Ci User2: Ci User1: Cmax 1. Merge the tasks of user 1 2. Global SPT Not truthful: if Blue declares to be interested inCi

15. Linear aggregation is unfair Two users with Ci (both own three tasks: 1,1,1 and 2,2,2).

16. MUSP(k:Cmax) • Inapproximability: • no algorithm better than (1,2,…,k) • Proof: consider the instance where each user has • one unit task (pi(u)=1) on one machine (m=1). • Cmax*(u) = 1 and there is no other choice than: • . . .

17. MUSP(k:Cmax) • Inapproximability: • no algorithm better than (1,2,…,k) • Proof: consider the instance where each user has • one unit task (pi(u)=1) on one machine. • Cmax*(u) = 1 and there is no other choice than: • . . . • Thus, there exists a user u whose Cmax(u) = k

18. MUSP(k:Cmax) • Algorithm (multiCmax): • Given a -approximation schedule  for each user • Cmax(u) ≤ Cmax*(u) • Sort the users by increasing values of Cmax(u) • Analysis: • multiCmax is a (,2, …, k)-approximation.

19. MUSP(k:Ci) • Inapproximability: no algorithm better than • ((k+1)/2,(k+2)/2,…,k) • Proof: consider the instance where each user has x • Tasks pi(u) = 2i-1. • Optimal schedule: Ci* = 2x+1 - (x+2) • SPT is Pareto Optimal (3 users blue, green and red): • . . . • For all u, CiSPT(u) = k(2x -(x+1)) + (2x -1) u • Ratio to the optimal = (k+u)/2 for large x

20. MUSP(k:Ci) Algorithm (single machine) Aggreg: Let (u) be the schedule for user u. Construct a schedule by increasing order of Ci((u))

21. MUSP(k:Ci) • Algorithm (single machine) Aggreg: • Let (u) be the schedule for user u. • Construct a schedule by increasing order of Ci((u))

22. MUSP(k:Ci) • Algorithm (single machine) Aggreg: • Let (u) be the schedule for user u. • Construct a schedule by increasing order of Ci((u)) • Analysis: Aggreg is (k,k,…,k)-approximation

23. MUSP(k:Ci) • Algorithm (extension to m machines): • The previous property still holds on each machine (using SPT individually for each user) • Local SPT

24. MUSP(k:Ci) • Algorithm (extension to m machines): • The previous property still holds on each machine (using SPT individually for each user) • Local SPT • Merge on each machine

25. MUSP(k:Ci) • Analysis: we obtain the same bound as before.

26. Mixed caseMUSP(k’:Ci;(k-k’):Cmax) • A similar analysis can be done, see the paper with Erik Saule for more details

27. Decentralized objective • In the previous analysis, the users had to choose among several objectives (expressed from the completion time). • The scheduling policy was centralized and global. • A natural question is « what happens with exotic objectives or with predefined schedules? »

28. Complicating the model:Multi-organizations

29. Context: computational grids m1 machines … Organization O1 … … m2 machines Organization O3 … Organization O2 … … m3 machines Collection of independent clusters managed locally by an « organization ».

30. Preliminary:single user, multi-organization Independent tasks are submitted locally by single users on « private » organizations:

31. Preliminary:single user, multi-organization Independent tasks are submitted locally by single users on « private » organizations:

32. Multi-organization • Problem: each organization has its own objective.We are looking for a centralized mechanism that improves the global behaviour without worsering the local solutions.

33. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

34. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

35. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

36. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

37. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

38. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

39. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

40. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm:

41. Multi-organization with Cmax • Algorithm: iterative load-balancing • The organizations are sorted by increasing load • The load of the more loaded one is balanced usinga simple list algorithm: • Analysis: bound 2-1/m for the global Cmax

42. Extension to parallel taskssingle resource: cluster Independent applications are submitted locally on a cluster. The are represented by a precedence task graph. An application is viewed as a usual sequential task or as a parallel rigid job (see [Feitelson and Rudolph] for more details and classification).

43. Cluster Local queue of submitted jobs … J3 J2 J1 … …

44. Job

48. overhead Computational area Rigid jobs: the number of processors is fixed.

49. Runtime pi #of required processors qi

50. Runtime pi #of required processors qi Useful definitions: high jobs (those which require more than m/2 processors) low jobs (the others).