CS 452/652 Winter 2026 - Lecture 7

Name Resolution, Measurements, CPU Caching

Jun 3, 2026 prev next

REF - Architecture Reference Manual

Name Resolution

• resolve service names (chosen by application) to tids (chosen by the kernel)
  • implicit/default starting point: tid of name server
  • tid-based communication facilitated by kernel (see 'Communication' earlier)
• pervasive topic in computer science: mapping name spaces to each other
  • systems: memory address - name for circuit, name for device register
  • programming: variable - name for memory location or register
  • operating system: file - name for data on disk (inode)
  • Internet: DNS - name for IP address
  • Internet: URL - name for remote file/service and access protocol
• recursive problem
  • ask authority to resolve the mapping, but how to resolve the name of the authority
  • need a closure mechanism - something to ground the recursion
  • name resolution always starts in a default context with a default starting point!
    • file system: kernel using / (slash)
    • Internet domain names: local resolver using . (dot)

Name Server

• names: null-terminated character arrays
  • maximum length? error? truncate?
• WhoIs() for non-existing name? error? block?
• RegisterAs() with previous registration for same name?
• design of name server (data structure and operation):
  • how many names?
  • how often is name server used? when?
  • is this latency-critical?
• note that RegisterAs() and WhoIs() are not system calls

Measuring Execution Time

• duration of operation? basic approach:

      start = clock();
      operation();
      stop = clock();
  

• variability

  • time required for operation() might vary each time you run it
    • interference?
  • do you want to:
    1. hide/smooth variability?
    2. measure and understand it?

• precision

  • how often does your clock tick?
  • are you trying to measure something that's faster than your clock ticks?

• overhead

  • clock() takes time
  • what you measure is actually the time for operation() plus the time for clock()
  • significance depends on how fast operation() is, relative to clock()

• measure multiple times:

      loop N times:
          start = clock();
          operation();
          stop = clock();
      endloop;
  

  • helps with variability
    • compute variance, outliers, distribution
  • does not help with precision or overhead problem

• inflate impact of operation:

      start = clock();
      loop N times:
          operation();
      endloop;
      stop = clock();
  

  • precision - increase N until N * operation() is much slower than your clock
  • overhead - increase N until overhead is insignificant

• additional overheads

  • loop execution (counter, branch) - if relevant, measure with nop
  • sometimes: dummy side effects needed to keep optimizer from eliding experiment code
    → N must be large enough to mitigate impact of these overheads
  • concurrent workflow requires start/stop coordination
  • warm-up period with non-regular performance

• experiment duration

  • fixed N - simple
  • fixed run-time - predictable, but more difficult to set up and run

Realtime Loop

• real-time with fixed period X? naive approach:

      loop:
        action();
        sleep(X);
      endloop;
  

  ... is not sufficient: duration of action(), errors in sleep()

• account for deviations from perfect timing:

      target = clock();
      loop:
        action();
        target += X;
        sleep(target - clock());
      endloop;
  

CPU Pipelining & Caching

• memory types & caches (REF, Section B2.7, etc.)
  • L1 instruction cache; L1 data cache; L2 unified/shared cache
  • branch target cache (branch predictors)
  • TLB (page translation cache)
  • write buffer: mediate fast CPU vs. slow RAM; coalesce writes
    • memory modes: Device vs Normal
    • caching modes: Write-Back, Write-Through, Non-Cacheable

Cache Setup & Maintenance

• Cache Maintenance
  • CTR_EL0 for cache information (REF, Section D7.5)
  • CCSIDR_EL1/CSSELR_EL1 for cache size (REF, Section D7.5)
  • L1d 128KB, L1i 192KB, L2 1MB (unified, shared)
• SCTLR_EL1
  • I and C flags for instruction and data cache respectively
  • controls EL0 and EL1 for Normal mode
    • memory barrier to enforce changes
  • Cache Maintenance
    • clean: make changes "permanent"
    • invalidate: avoid stale reads
  • status changes
    • enabled → disable: clean cache?
    • enabled → enable: clean cache?
    • disabled → disable: nothing
    • disabled → enable: depends on previous state
      • enabled → disable → enable
        information in cache might be stale
        invalidate cache before disable or before re-enable?
• experiment!