Downloaded 63 times
![Linux 2.6 Scheduler
(2003-2007)
struct runqueue {
struct prioarray *active;
struct prioarray *expired;
struct prioarray arrays[2];
140 different queues (for
};
each processor)
struct prioarray {
0-99 for “real time” processes
int nr_active; /* # Runnable */
100-139 for “normal” processes unsigned long bitmap[5];
struct list_head queue[140];
Bit vector of ready-to-run
};
Scheduler picks first process from highest-priority queue with a ready process
10](https://image.slidesharecdn.com/class12-inked-140304131029-phpapp02/75/Scheduling-in-Linux-and-Web-Servers-11-2048.jpg)
Uploaded byDavid Evans
Scheduling in Linux and Web Servers
The document discusses scheduling mechanisms in Linux from its early versions to recent developments, outlining process types, priority handling, and improvements in the Linux scheduler. It also addresses challenges faced by web servers, notably in handling overload situations like those experienced by healthcare.gov, proposing strategies such as content simplification, caching, and increased server capacity. Lastly, it emphasizes the importance of monitoring and measuring performance to optimize scheduling policies and resources effectively.
More Related Content
Similar to Scheduling in Linux and Web Servers
More from David Evans
Scheduling in Linux and Web Servers
- 1. Scheduling in Linux andWeb Servers
- 2. Plan for Today Schedulingin Linux (2002-today) Scheduling Web Services Submitting PS3: - Schedule demo (sign up soon!) - Web submission form (11:59pm tomorrow) - Benchmark submission - Post-demo assessment (teammate evaluation) leaderboard.html 1
- 3.
- 4. Linux Scheduler beforeV2.6 (2002) Three types of processes: #define SCHED_OTHER 0 Normal user processes #define SCHED_FIFO 1 Non-pre-ementable #define SCHED_RR 2 Real-time round-robin Not (fully) pre-emptive: only user-level processes could be pre-empted Select next process according to “goodness” function 3
- 5. /* linux/kernel/sched.c * Thisis the function that decides how desirable a process is. * You can weigh different processes against each other depending * on what CPU they've run on lately etc to try to handle cache * and TLB miss penalties. * * Return values: * -1000: never select this * 0: out of time, recalculate counters (but it might still be selected) * +ve: "goodness" value (the larger, the better) * +1000: realtime process, select this. */ static inline int goodness(struct task_struct * p, int this_cpu, struct mm_struct *this_mm) { int weight; /* * Realtime process, select the first one on the * runqueue (taking priorities within processes * into account). */ if (p->policy != SCHED_OTHER) { weight = 1000 + p->rt_priority; goto out; } /* * Give the process a first-approximation goodness value * according to the number of clock-ticks it has left. * * Don't do any other calculations if the time slice is * over.. */ /* linux/kernel/sched.c * This is the function that decides how desirable a process is. * You can weigh different processes against each other depending * on what CPU they've run on lately etc to try to handle cache * and TLB miss penalties. * * Return values: * -1000: never select this * 0: out of time, recalculate counters (but it might still be selected) * +ve: "goodness" value (the larger, the better) * +1000: realtime process, select this. */ static inline int goodness(struct task_struct * p, int this_cpu, struct mm_struct *this_mm) { … 4
- 6. static inline intgoodness(struct task_struct * p, int this_cpu, struct mm_struct *this_mm) { int weight; /* Realtime process, select the first one on the runqueue (taking priorities into account). */ if (p->policy != SCHED_OTHER) { weight = 1000 + p->rt_priority; goto out; } /* Give the process a first-approximation goodness value according to the number of clock-ticks it has left. Don't do any other calculations if the time slice is over.. */ weight = p->counter; if (!weight) goto out; #ifdef __SMP__ /* Give a largish advantage to the same processor... (equivalent to penalizing other processors) */ if (p->processor == this_cpu) weight += PROC_CHANGE_PENALTY; #endif /* .. and a slight advantage to the current MM (memory segment) */ if (p->mm == this_mm) weight += 1; weight += p->priority; out: This is the whole goodness function from V2.5 return weight; scheduler (only edited formatting to fit on slide). } 5
- 7. What is therunning time of the Linux 2.2-2.5 Scheduler? 6
- 8. What is the runningtime of the Linux 2.2-2.5 Scheduler? 7
- 9.
- 10. Linux 2.6 Scheduler(2003-2007) 140 different queues (for each processor) 0-99 for “real time” processes 100-139 for “normal” processes Bit vector keeps track of which queues have ready to run process Scheduler picks first process from highest priority queue with a ready process Given time quantum that scales with priority 9
- 11. Linux 2.6 Scheduler (2003-2007) structrunqueue { struct prioarray *active; struct prioarray *expired; struct prioarray arrays[2]; 140 different queues (for }; each processor) struct prioarray { 0-99 for “real time” processes int nr_active; /* # Runnable */ 100-139 for “normal” processes unsigned long bitmap[5]; struct list_head queue[140]; Bit vector of ready-to-run }; Scheduler picks first process from highest-priority queue with a ready process 10
- 12. What is therunning time of the Linux 2.6 Scheduler? 11
- 13. (Sadly, O(1) schedulerhas no Facebook page.) 12
- 14.
- 15. Rotating Staircase DeadlineScheduler This is exactly stride scheduling (but with different terminology)! 14
- 16.
- 17.
- 18.
- 19.
- 20. What is therunning time of the Linux 2.6.23+ Scheduler? Not called the θ(log N) scheduler – by Linux 2.6.23 marketing matters: “Completely Fair Scheduler” 19
- 21. (In practice) Whatis log2 N? 20
- 22. What resources shouldscheduler be maximizing utility of? 21
- 23. Key Resource: Energy! Imagefrom http://arstechnica.com/apple/2013/10/os-x-10-9/12/ 22
- 24.
- 25.
- 26.
- 27. Timer Coalescing Images fromhttp://arstechnica.com/apple/2013/06/how-os-x-mavericks-works-its-power-saving-magic/ 26
- 28. OS Schedulers Recap UseResources Well Limit unnecessary switching, Save Energy Low cost of scheduler itself Make good decisions Locally: pick the most important process Globally: provide good system performance 27
- 29.
- 30. Web Server Overload! healthcare.gov Rateof incoming requests > Rate server can process requests 29
- 31.
- 32.
- 33. “When the meetingsended at a CMS outpost in Herndon, Va., at about 7:00 p.m., the rescue squad already on the scene realized they had more work to do. One of the things that shocked Burt and Park’s team most—“among many jaw-dropping aspects of what we found,” as one put it—was that the people running HealthCare.gov had no “dashboard,” no quick way for engineers to measure what was going on at the website, such as how many people were using it, what the response times were for various click-throughs and where traffic was getting tied up. So late into the night of Oct. 18, Burt and the others spent about five hours coding and putting up a dashboard.” 32
- 34. Developer Benchmarks • Findbottlenecks: know what to spend time optimizing • Measure impact of changes • Predict what resources you will need to scale service Goal is a benchmark that represents the actual usage 33
- 35. Strategy 1: Shrink andSimplify Your Content 34
- 36. 5 September 2001 11September 2001 archive.org captures of New York Times (http://www.nytimes.com) 35
- 37.
- 38. 11 September 2001 5September 2001 37
- 39. Strategy 2: Cache toSave Effort 38
- 40.
- 41. “Looking over thedashboard that Park, Burt and the others had rigged up the prior Friday night, Abbott and the group discovered what they thought was the lowest-hanging fruit--a quick fix to an obvious mistake that could improve things immediately. HealthCare.gov had been constructed so that every time a user had to get information from the website's vast database, the website had to make what's called a query into that database. … The team began almost immediately to cache the data. The result was encouraging: the site's overall response time--the time it took a page to load-dropped on the evening of Oct. 22 from eight seconds to two. That was still terrible, of course, but it represented such an improvement that it cheered the engineers. They could see that HealthCare.gov could be saved instead of scrapped.” 40
- 42. Strategy 3: Buy (orRent) More Servers 41
- 43.
- 44.
- 45.
- 46. “A series ofhardware upgrades had dramatically increased capacity; the system was now able to handle at least 50,000 simultaneous users and probably more. There had been more than 400 bug fixes. Uptimes had gone from an abysmal 43% at the beginning of November to 95%. And Kim and her team had knocked the error rate from 6% down to 0.5%. (By the end of January it would be below 0.5% and still dropping.)” 45
- 47. Using More Servers Server1 Dispatcher Server 2 Server 3 46
- 48. Sharing State Server 1 Dispatcher Server2 Database Server 3 47
- 49. Distributed Database Server 1 Dispatcher Database Database Server2 Database Server 3 Database 48
- 50. Maintaining Consistency Server 1 Dispatcher Database Database Server2 Database Server 3 Database 49
- 51. 1. Replication Database Reads areefficient Server 1 Writes are complex and risky 2. Vertical Partitioning Database Dispatcher Split database by columns Server 2 3. Horizontal Partitioning (“Sharding”) Database Split database by rows Server 3 4. Give up on consistency and functionality “NoSQL” (e.g., Cassandra, MongoDB, BigTable) Database 50
- 52. Scalable Enough? Server 1 Dispatcher Database Database Server2 Database Server 3 Database 51
- 53. Distributed Denial-of-Service Server 1 Dispatcher Database Database Server2 Database Server 3 x 2000 machines Botnet Database 52
- 54.
- 55.
- 56.
- 57. What should theserver’s goal be? 56
- 58. What is thebottleneck resource? Zhtta Disk (files) Cache 57
- 59. Connecting to theNetwork ISP Router zhtta Cache Disk (files) 58
- 60. Cisco Nexus 7000(~$100K) 48 Gb/s per slot x 10 10 Gb/s x 4 per switch Your server 250 Mbits/s $20/month 59
- 61. Shortest Remaining ProcessingTime-first 60
- 62. How close tothis can you get for PS3? 61
- 63. Charge Measurement (“dashboard”) isessential for improving performance Important to measure the right things! Scheduling policies: Avoid wasting resources Make trade-offs that align with system goals PS3 Due tomorrow (Wednesday) at 11:59pm If you haven’t already scheduled your demo, do so now! 62
Editor's Notes
- #4 http://www.linuxjournal.com/article/3910