14
A User-Lever Concurrency Manager Hongsheng Lu & Kai Xiao

A User-Lever Concurrency Manager

Embed Size (px)

DESCRIPTION

A User-Lever Concurrency Manager. Hongsheng Lu & Kai Xiao. 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 - PowerPoint PPT Presentation

Citation preview

Page 1: A User-Lever Concurrency Manager

A User-Lever Concurrency Manager

Hongsheng Lu & Kai Xiao

Page 2: A User-Lever Concurrency Manager

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

Page 3: A User-Lever Concurrency Manager

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.

Page 4: A User-Lever Concurrency Manager

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

Page 5: A User-Lever Concurrency Manager

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 speedToo Many process blockedWriting speed >= Flushing speed

Processes blocked

Running time = 4.0 s Running time = 4.5 sn=1

Running time = 189 sn=90

Running time = 220 s

Writing speed < Flushing speedProcesses blocked

Page 6: A User-Lever Concurrency Manager

Solution Feedback & Record(FR)

What kind of processes should be blocked?

Block

Not Kill

Page 7: A User-Lever Concurrency Manager

Solution

Block

Not Kill

Page 8: A User-Lever Concurrency Manager

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 one3. If either resource is under usage, activate one of appropriate blocked procs immediately

Page 9: A User-Lever Concurrency Manager

Benchmark SetInput 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

Increase/1

Flat/0

Big/1

Small/0

Big/1

Small

/0

Burst/1

Flat/0

Yes/1

No/0

1 0 1 0 1 0 0 0

0 1 1 1 0 1 1 0

0 0 0 1 0 1 1 1B1 : Only CPU procs with flat memory requirementB1': Only CPU procs with increase memory requirementB2 : IO procs with few CPU procs of flat memory requirementB2': IO procs with few CPU procs of increase memory requirementB3 : 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)

Page 10: A User-Lever Concurrency Manager

EvaluationB1 B1’ B2 B2’ B3 B3’ B4 B4’ B5 B5’

Job length

300 300 340 340 240 240 500 500 1000 1000

Best N 120 80 160 80 140 60 120 80 220 180Runtime/s(Best N)

1545 2137 434 467 542 663 1729 2166 3013 3625

RT. Right Record

1557 2041 429 445 547 620 1715 2083 2981 3469

RT. No Record

1560 2084 433 462 543 653 1720 2130 3004 3570

RT. Wrong CPUs

Record

1564 2109 436 485 555 642 1734 2164 3036 3611

RT. Wrong Output/CPUs Record

1570 2093 450 482 552 725 1729 2379 3172 3992

Page 11: A User-Lever Concurrency Manager

Conclusion1. Record accuracy

FR Performance

Right Record No Record Wrong CPUs Wrong IO/CPUs

2000

2020

2040

2060

2080

2100

2120

Right Record No Record Wrong CPUs Wrong IO/CPUs560

580

600

620

640

660

680

700

720

740

Page 12: A User-Lever Concurrency Manager

Conclusion1. 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

B3 B3'0

100

200

300

400

500

600

700

FRBest N

B5 B5'1000

1500

2000

2500

3000

3500

4000

FRBest N

2. Memory

FR with right records behaviors good

Page 13: A User-Lever Concurrency Manager

Conclusion1. Record FR

With increasing memory, the improvement is more obvious when job is longer

2. Memory

FR with right records behavior good

B3' B4' B5'0

500

1000

1500

2000

2500

3000

3500

4000

FRBest N

Page 14: A User-Lever Concurrency Manager

Conclusion1. Record FR

2. Memory

FR with right records behavior good

2. Job length

Improvement is more obvious

Questions?

Thank you !