CS 452/652 Winter 2024 - Lecture 7

Name Resolution, Measurements, Caches

Jan 30, 2024 prev next

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
- 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 usnig / (slash)
  - Internet domain names: local resolver using . (dot)

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

duration of operation? basic approach:

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

overhead
- clock() takes time
- what you measure is actually the time for something() plus the time for clock()
- significance depends on how fast operation() is, relative to clock()
precision
- how often does your clock tick?
- are you trying to measure something that's faster than your clock ticks?
variability
- time required for something() might vary each time you run it
  - interference?
- do you want to:
  1. hide/smooth variability?
  2. measure and understand it?
measure multiple times:
```
    loop N times:
        start = clock();
        operation();
        stop = clock();
    endloop;
```
- helps with variability
  - compute variance, outliers, distribution
- does not help with overhead or precision problem
inflate impact of operation:
```
    start = clock();
    loop N times:
        operation();
    endloop;
    stop = clock();
```
- overhead - increase N until overhead is insignificant
- precision - increase N until what Nx operation() is much slower than your clock
additional overheads
- loop execution (counter, branch) - if relevant, measure with nop
- concurrent workflow requires start/stop coordination
- warm-up period with non-regular performance
- sometimes: dummy side effects needed to keep optimizer from eliding experiment code
  → N must be large enough to mitigate impact of these overheads
experiment duration
- fixed N - simple
- fixed run-time - predictable, but more difficult to set up and run

account for deviations from perfect timing:

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