Cooperative Disk Management with ECOSystem

1. Cooperative Disk Management with ECOSystem Emily Tennant Mentor: Carla Ellis Duke University

2. Outline • Milly Watt Overview • Cooperative file operations • Building blocks for efficient hard disk management • Read and write requests • Design Issues • Testing

3. Milly Watt Project • Energy consumption in use of computing devices is an important problem – emphasis on power management • Mobile computing: Extend battery lifetime • Traditional platforms: Reduce heat production and fan noise • Conserve energy resources (lessen environmental impact) • Energy should be managed as a “first class” system resource • Partnership between applications and system in setting energy policy • What can be done within the OS to achieve energy-related goals without requiring applications to change in any way?

4. ECOSystem • Energy Centric Operating System Goals: • Manage allocation of energy to achieve a desired battery lifetime without requiring application modifications • Allocate energy proportionally among active applications as it becomes a scarce resource • Unified Currentcy Model • Energy accounting and allocation are expressed in a common currentcy. • Unifies hardware resource management • One unit of currentcy represents right to consume certain amount of energy within a fixed amount of time (0.01 mJ).

5. Currentcy Allocation Battery lifetime achieved by limiting battery discharge rate Per-epoch recalculation of discharge rate and allocation of currentcy Energy allocated proportionally among tasks – “allowance” Currentcy Accounting Pay as you go for resource use – resource containers No more currentcy  no more service. Charging policies specific to device type ECOSystem Mechanisms

6. The Next Step • The next step for ECOSystem • Improve energy efficiency • Take advantage of energy aware applications • Vision • Create a set of API extensions permitting applications to pass application-specific information to the OS. • Use this information to manage disk accesses more efficiently. • Specific Goals • Simple interface • Minimal changes – backward compatibility • Energy savings in terms of currentcy

7. Disk Management • Hard drive states • Maximize time spent in standby • Minimize transitions from standby to active state • Traditional systems: disks managed individually • Goal: use Currentcy Model to explicitly batch requests for disk access more efficiently • Terms: read, write, update • One Watt = one Joule per second

8. Related Work • Recent submission to OSDI conference: • Andreas Weissel, Björn Beutel, Frank Bellosa. Cooperative I/O—A Novel I/O Semantics for Energy-Aware Applications. • Goal: “demonstrate benefits of application involvement in operating system power management.” • Coop-I/O – an approach to reduce power consumption of devices (disk) • Involves hardware, operating system, I/O interface for energy-aware applications

9. Main Elements – Coop-I/O • New cooperative file operations • read_coop(), write_coop(), open_coop() • New parameters: time-out and cancel flag • If disk is inactive, delay disk request for length of time-out parameter • Possible to abort accesses after time-out period • Energy-efficient update mechanism • Update of cached disk blocks is batched to maximize the time hard disk can spend in standby mode. • OS controls hard disk modes • Disk drive is switched into low-power mode according to an adaptive algorithm. • “device-dependent time-out with early shutdown (DDT/ES)”

10. Cooperative I/O in ECOSystem • New cooperative file operations • New system calls (readb, writeb) with added parameter(s). • Deferrable disk requests • Abortable file operations? • Energy-efficient update mechanism • Updates deferred to create bursty disk access • Energy-efficient update strategies integrated into write process • OS control of disk drive • Motivation of adaptive algorithm for powering down disk drive?

11. P1 P2 P3 Disk spins up Bidding • How do we couch the cooperative, deferrable file operations of Coop-I/O in terms of ECOSystem’s currentcy? • “Bidding” process Entry Price • Inflated entry price delays disk spinup to ensure that multiple processes have generated disk requests. • Each process “bids” the amount of currentcy it is willing to contribute towards the entry price. Total Bid Time

12. Priorities • Motivating Question: How can we implement the bidding process in a useful and intuitive interface (similar to Coop-I/O)? • Currentcy is dynamic – difficult for application to assign directly. • Create static priorities. • Map priorities to a currentcy amount for bid. • What type of priorities could be created? • Integer sets (1-10, 1-100) • Real-numbered intervals • Dynamic priorities Time willing to wait Priority (and currentcy bid)

13. Resource Container Available_currentcy Ticket Percentage of available currentcy Available_currentcy priority Ticket Bid Percentage of entry price Priority Mapping Priority to Bid • Takes place within OS – application knows nothing about currentcy • Involves resource container • May require resource container alteration • Bid, priority, time-out, etc.

14. A Simple Mapping Model • Assume numeric priority. • Priority corresponds directly to percentage of available currentcy that is allocated to bid. • Example: priority = 5, available currentcy = 1000mJ • BID = 500mJ • Remainder of available currentcy can be used (CPU, NIC) while process waits to access disk (asynchronous access). • Overhead issues BID = available_currentcy * (priority/10)

15. System call is generated. readb(……...., [priority]); Verify that data is uncached and disk is inactive. Priority bid. “Issue bid” – store bid amount in resource container. Process enters waitqueue. 6. Update daemon checks Σbids (reads and writes) against the entry price. When Σbids  entry price, disk spins up. Disk access enters runqueue. Resource container is debited for cost of access. Data is read into buffer cache. Sample Read Disk Accesses

16. Write Disk Access • More complex! • What does “deferrable write” mean? Do we defer writing to the buffer cache or flushing the buffers to the disk? • ECOSystem: Unified write/update policy • Writes • Data is written to buffer immediately. • Process bids toward disk spin up (and buffer flushing) - only requires resource container. • Updates • Bids vs. entry price delays disk spinup. • Disk spinup activates buffer flushing. • Decreasing entry price guarantees updates.

17. Is buffer already cached? Write to buffer cache. Is disk active? Bid to read buffer in. Flush buffer. Bid. Sample Write Disk Accesses writeb(…,…,…,[priority]);

18. Reads: P1 pid P1 P2 P2 pid Writes: P1 P1 P2 Design Issues • Simplest case (first • implementation): • “first-reader” • accumulate only P1’s bid • charge only P1 for disk access • Intuitive Goal: • “sum” • accumulate bids from P1 and P2 • charge P1 and P2 • Simplest case: • - “last writer” • save only P2’s bid • charge only P2 • Intuitive Goal: • “sum” • accumulate bids from P1 and P2 • charge P1 and P2

19. Synthetic Benchmarks Simple read/write programs. Create scenarios where energy-savings are most obvious. Simulate different workloads: Multiple simultaneous cooperative tasks Mix cooperative and non-cooperative tasks. “Real” Application Audio/video player, image viewer. Test performance in non-optimized, “real-life” situations. Compare results on: ECOSystem unthrottled (Coop-I/O) Current ECOSystem implementation ECOSystem with cooperative implementation Testing

20. Summary • New system calls for basic file operations. • Priority can be specified by application. • Priority determines amount of currentcy in bid. • Total bids for disk access must exceed entry price. • Interaction between decreasing entry price and bids for disk access works toward efficiently batching disk accesses while guaranteeing that non-abortable accesses occur.