1 / 7

Timing Forensics

This article discusses the differences between benchmarks and microbenchmarks in the context of timing forensics. It explores the measurement of overall system behavior and fine-grain behavior, as well as synchronous and asynchronous timing. Various mechanisms to enforce determinism and the use of kernel modules are also covered.

juliod
Download Presentation

Timing Forensics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Timing Forensics Chris Gill, Son Dinh, and Brian Kocoloski CSE 522S - Advanced Operating Systems Washington University in St. Louis St. Louis, MO 63130

  2. Benchmarks vs. Microbenchmarks • Benchmarks focus on overall system behavior • Timing, resource usage, blocking, etc. • May depend on whether processes are compute-bound, I/O bound, or both, and specific bottlenecks • Microbenchmarks focus on fine-grain behavior • Timelines for events due to different mechanisms • Results depend less on other policies/mechanisms • Give basic units of measure to reason about • We will explore these in today’s studio CSE 522S – Advanced Operating Systems

  3. Synchronous vs. Asynchronous Timing • Activities within a thread are synchronous • Easy to measure by taking before/after timestamps • E.g., latency to issue a request to create a thread • Asynchronous w.r.t. kernel, other threads • Need multiple timestamps in multiple places • Causal nature of mechanisms must be considered • Sometimes, only relativistic measures are possible • But, with a common clock, also detailed timing • Need a clock that is synchronized across cores CSE 522S – Advanced Operating Systems

  4. Asynchrony-Safe Microbenchmarks • Must use independent memory locations • E.g., preallocated array of timestamps, with each index used independently by various activities • Timestamping must be quick and regular • The overhead should should be as deterministic as possible, so as not to change timing behavior too much (e.g. don’t allocate dynamic memory) TS[0] TS[1] TS[2] TS[3] TS[4] TS[5] CSE 522S – Advanced Operating Systems

  5. Other Mechanisms to Enforce Determinism • Pin threads to cpus (don’t let Linux migrate threads willy nilly) • Preallocate memory • Run very time sensitive workloads in kernel threads • Why? Linux generally does not involuntarily preempt kernel threads CSE 522S – Advanced Operating Systems

  6. Studio Exercises Today Write a simple kernel module • Stores an array of timestamps to record timing behavior • Launches threads and timers and instruments them • Calculates micro-benchmark latencies for different behaviors involving different mechanisms Use ktime_get() to record ktime_t timestamps • Into the kernel module’s timestamp array Calculate and print out different timing intervals • Latency to issue a thread creation request • Latency from creation request to when thread starts • Wakeup timing, synchronization behavior, etc. CSE 522S – Advanced Operating Systems

  7. Resources that may be useful • LKD ch 17 (kernel modules) • LKD ch 11 (timers) • LKD ch 3 (kernel thread creation) • Link to the CSE 422S studio that introduces kernel modules: • https://www.cse.wustl.edu/~brian.kocoloski/courses/cse422s/studios/06_modules.html • Link to a simple kernel module stub from LKD ch 17: • https://www.cse.wustl.edu/~brian.kocoloski/courses/cse422s/studios/simple_module.c CSE 522S – Advanced Operating Systems

More Related