Application Controlled File CachingPaging cs530 2001 Fall

1
Application Controlled File Caching/Pagingcs530
2001 Fall

• Instructor Joonwon Lee

2
Overview

• motivation
• increasing speed gap necessitates file cache
• Improving file cache performance
• application control on replacement
• prefetching
• disk scheduling
• others write-back policies, clustering, etc.
• Research problems
• application controlled caching
• good cache allocation policy that is no worse
  than existing integrated file cache
• prefetching
• integration with caching and disk scheduling

3
Traditional Caching Scheme
4
Why Application Controlled

• One Policy does not fit all
• kernel policy is not always the best
• Applications often know better than kernel
• DBMS, test retrieval tools, multimedia,
  simulation, ..

5
Cache Allocation

• Problem
• how to allocate buffer cache pages among
  processes?
• Two level replacement
• kernel manages allocation
• kernel decides which process should give up a
  cache block upon miss
• user process manage replacement
• processes decide which block to evict when asked
  by kernel
• Criteria for allocation policies
• when kernel does it, it is the same as existing
  schemes
• smart processes benefit
• stupid processes shouldnt hurt other processes

6
LRU-SP

• maintains an LRU list of all cache blocks
• on a miss, choose the process who owns the LUR
  block
• swapping
• prevent discrimination against smart processes
• A and B belong to P, and A is the globally LRU
  block, but P chooses B to be replaced
• kernel puts A in Bs position

7
Placeholders

• prevent stupid processes from hurting others
• P was the foolish one
• after replacing B, P accesses B next (so stupid!)
• when a process makes a decision against the
  global LRU,
• kernel prepares a placeholder for B pointing A
• when access to B is a miss, replace A with B

B
8
Two Level Replacement
9
Design Alternatives

• User/kernel interaction
• upcall expensive
• fixed menu of policies inflexible
• priorities of file(or blocks) high overhead
• combination of priorities and policies
• applications assign priorities to files and file
  blocks
• application specify replacement policies for each
  priority
• LRU, MRU,

10
Implementation
3000 lines
11
Implementation

• Split the buffer cache into two components.
• BUF Buffer Cache Module
• cache management
• bookkeeping
• the implementation of the allocation policy.
• ACM application control module
• implements the interface
• proxy for user-level managers
• Data structures
• Each managed process has a manager structure.
• Manager structure has a queue per priority.

12
Prefetching

• Why prefetching?
• easy to know about future accesses in many cases
• information from program
• prediction by heuristics
• ways to use this knowledge
• prefetching
• optimal caching
• Assuming that process Ps next accesses the
  question is

13
Tradeoffs of Prefetching

• Overlap CPU time with IO
• Earlier prefetch evicts useful block from cache
• Problem Formulation
• knowledge a priori
• future accesses
• size of the cacah K blocks
• cost fetch a block from disk F
• answers sought for
• when to fetch
• which to fetch
• which to replace(evict)
• goal
• minimize elapsed time

14
Optimal and Approximation

• Properties of Optimal Algorithms
• always fetch the next missing block
• always replace the block that will be used
  furthest in future
• never replace A for B if A will be used before B
• do not delay a fetch unless waiting for better
  chance
• Controlled-Aggressive
• fetch at the earliest time
• allowed b the rule and when the disk is idle
• make optimal replacement

15
Limited Lookahead

• Cases of incomplete lookahead knowledge
• no prediction
• wrong predictions
• limited(N) predictions
• ACFS compares prediction with actual references
• access to an unpredicted block
• treat it like Unix buffer cache algorithm
• predicted access does not occur
• ignore mistakes when it is few
• ignore the whole prediction when it is too many

16
Limited Lookahead

• when there are only N predictions
• normal prefetching, but replacement becomes
  difficult
• identify cache blocks that are not in the
  prediction list
• let application choose a victim among them
• Applications policy and prediction list may
  conflict
• respect policy for long term behavior
• respect prediction list for near-term behavior
• open research issue

17
Performance

• Applications
• cscope C-source examination tool (MRU)
• dinero cache simulator (MRU)
• glimpse text index/retrieval system (MRU2
  priority)
• ld link editor (toss immediately)
• postgres-join join query on a database (LRU 2
  priority)
• sort external sort utility (MRU 2 priority)
• Results-Single Application
• Execution time
• Most in the 80-100 of elapsed time range.
• Best results are about 50 of elapsed time
  (cscope, query 1).
• Number of I/Os
• Most in the 70-100 range.
• Best results are 20 of the normal I/Os (cscope,
  query 1).

18

• Results-Multiple Applications
• Elapsed time improves up to 5-30 range.
• Number of I/Os saved in the 10-30 range.
• Other Results
• Demonstrate that swapping is necessary (without
  it, we can decrease performance).
• Demonstrate that placeholders are necessary.
• Demonstrate that their algorithm does not isolate
  applications.
• Bad decisions put heavier demands on the I/O
  system.
• Bad decisions occupy cache blocks for longer
  periods of time.
• Smart processes help other processes dumb
  processes hinder them.

19
Multiple Processes Performance
20
Application-Controlled Paging

• why user-controlled something?
• computing usages are too diverse
• multimedia data
• real time
• personal computing
• large scientific application (usually parallel
  computing)
• a general OS cannot satisfy the needs that come
  from such diversity
• User-controlled what?
• almost any part of OS
• scheduling
• memory management
• file system
• network protocol
• security

21
Application-Controlled Paging

• External pager
• a paging mechanism controlled by user
  (applications)
• kernel swaps in/out a page
• extern pager decides which page(s) to swap
• Issues applications doesnt know and cant
  control
• the amount of memory available to it
• some programs can use as much memory as it is
  given
• what parts of it are kept in the memory
• some data accesses are predictable
• Some solutions
• allow applications to pin pages in memory
• disable OS ability to shared memory
• hard to know how much to pin
• allow application to advise VM system
• madvise() system call
• very primitive and complex mechanism

22
Segment Manager

• segment manager
• user level pager
• reclaims page frames
• writeback page frames

23
Segment Manager

• on page fault
• kernel forwards this event to the segment manager
  via signal or interrupt
• system call
• SetSegmentManager(seg, manager)
• specify the manager of a segment
• MigratePages(srcSeg, dstSeg, flags)
• move pages from a segment to another
• ModifyPageFlags(seg, flags)
• set/clear dirty bit, protection
• GetPageAttribute(seg, pages)
• determine the flags and mapping of pages
• the manager can be a part of the application
• recursive page faults may occur
• a manger pins its stack into memory

24
Application-Controlled Paging

• how a manager gets a free page
• from a free-page segment that it manages
• reclaim a page from another segment it manages
• request an additional page from the kernel
• System page cache manager
• the controller of the machines global memory
  pool
• segment managers get segments from this
• it may approve, deny, or partially fulfill
  requests

25
Memory market model

• until now, scheduling is for the time a program
  uses
• with multiprocessors memory will be more
  contended than CPU
• charges each process for space_used X time
• an application requests an amount of dram
  initially
• the kernel allocates dram according to system
  status and user request
• applications choose if they want large memory to
  be executed fast OR
• small memory since it is not very urgent
• questions remain
• interactions with CPU scheduling (read another
  paper)

26
Application-Controlled Paging

• Summary
• external pager is a trend
• OS should provide abstractions of the hardware
  complete in
• functionality (dont hide useful functionality)
• performance (dont hide performance)
• other user-controlled approaches
• gang scheduling on parallel machine
• scheduler activation
• user-level devices and file system