1. A User-Lever Concurrency Manager Hongsheng Lu & Kai Xiao

2. Motivation  Modern Computers with multiple resources  Multi-core processor, large memory, many disks, etc.  Given a batch of independent programs and commands  command 1: cp a.tar.gz b. tar.gz  command 2: mc_dose_calculation inputdata.txt  command 3: … et al.  Can we guarantee to use full horsepower of multiple resources in order to finish them as soon as possible?  Weapon: Concurrency

3. Problem  Physical concurrency makes effective parallelism and improves the performance  However, over loading concurrency level would actually deteriorate the system running performance  Low: wasting computing horsepower  High: performance comes down  Mission of our controller: dynamically adjust the concurrency level.  Requirement: monitoring and controlling  First step: understanding system behavior under different concurrency level.

4. Observation: CPU bound  CPU bound test : Simulation program Observation: 99% CPU for user Observation: Swap-in and Swap-out begin If increase the workload of application

5. Observation: IO bound  IO bound test: Write 50MB data to disk per program (30 total)  Extreme test: Write 1GB data to disk per program (90 total) Writing speed >> Flushing speed Too Many process blocked Writing speed >= Flushing speed Processes blocked Running time = 4.0 s Running time = 4.5 s n=1 Running time = 189 s n=90 Running time = 220 s Writing speed < Flushing speed Processes blocked

6. Solution Feedback & Record(FR) Block Not Kill

7. Solution Block Not Kill

8. Solution Block Not Kill 1. If there are procs blocked, don’t fork new procs. 2. Blocked procs are activated after some time one by one 3. If either resource is under usage, activate one of appropriate blocked procs immediately

9. Benchmark Set Input size Input pattern Calculate Amount Memory Pattern Memory Size Output Size Output Pattern Network needed Big /1 Small /0 Burst/ 1 Flat /0 Big/ 1 Small /0 Increa se/1 Flat /0 Big/ 1 Small /0 Big /1 Small /0 Burst /1 Flat /0 Ye s/1 No /0 10101000 01110110 00010111 B1 : Only CPU procs with flat memory requirement B1': Only CPU procs with increase memory requirement B2 : IO procs with few CPU procs of flat memory requirement B2': IO procs with few CPU procs of increase memory requirement B3 : Random procs with flat memory requirement (Short length) B3’: Random procs with increase memory requirement (Short length) B4 : Random procs with flat memory requirement (Medium length) B4': Random procs with increase memory requirement(Medium length) B5 : Random procs with flat memory requirement (Large length) B5': Random procs with increase memory requirement (Large length)

10. Evaluation B1B1’B2B2’B3B3’B4B4’B5B5’ Job length 300 340 240 500 1000 Best N 12080160801406012080220180 Runtime/s (Best N) 154521374344675426631729216630133625 RT. Right Record 155720414294455476201715208329813469 RT. No Record 156020844334625436531720213030043570 RT. Wrong CPUs Record 156421094364855556421734216430363611 RT. Wrong Output/CPU s Record 157020934504825527251729237931723992

11. Conclusion 1. Record accuracy FR Performance

12. Conclusion 1. Record FR When benchmark needs increasing memory, FR with right record is better than Best N While benchmark with flat memory requirement, FR is almost equal to best N 2. Memory FR with right records behaviors good

13. Conclusion 1. Record FR With increasing memory, the improvement is more obvious when job is longer 2. Memory FR with right records behavior good

14. Conclusion 1. Record FR 2. Memory FR with right records behavior good 2. Job length Improvement is more obvious