Python数据结构代写 | SystemTap to make observations about the Linux kernel

本次代写主要为python数据结构和算法相关

Description

In lab 1, your main goal was to begin to get comfortable with using SystemTap; you were able to use SystemTap to make observations about the Linux kernel, and to make observations about running user processes.

In lab 2, we’re going to keep using SystemTap, but this time we’re going to be using SystemTap to make observations about processes. Specifically, we’re going to be making observations about processes as they change state and how they move through the scheduler on a running Linux system.

Before the lab

In this lab, you’re going to be using various functions and probes that are provided by SystemTap (you don’t have to write these). SystemTap includes a SystemTap Tapset Reference Manual, which is effectively API documentation for SystemTap itself — the reference manual is a listing of and documentation for all of the probes and functions that you can use in SystemTap scripts.

Before you get to the lab you need to do a few different things:

You probably also want to have the SystemTap Beginner’s Guide and the SystemTap tutorial available.

Exercises

For each of the following exercises, you should write an explanation of the behaviour that you observe (i.e., what exactly is this SystemTap script printing out about the running kernel/system/application?). You should limit yourself to 1–2 sentences. You can record these observations in a Markdown-formatted README.md file.

You should organize your README.md file into sections for each exercise, and you should list the name of the SystemTap script that you’ve written/modified. You should also capture an output screenshot for every exercise, and refer to that screenshot in your README.md file using the Markdown syntax for including an image () so that your TA has some context about what you observed, since the observations that different students make may be different from run to run.

Exercise 1

Write a script to monitor and analyze the state transitions of a target process. You will use the scheduler.* probes to monitor process state transitions by probing on scheduler.ctxswitch or scheduler.process_exit.

Look carefully at the list of variables that are available within the scheduler.ctxswitch probe to decide how you know when a process is being switched on or off the CPU by the scheduler (this is on page 207 of the SystemTap Tapset Reference Manual). Specifically, look at all of the *_pid variables.

You should print out the following information on every context switch for your process:

You can get the CPU ID using the task_cpu() function (on page 86 of the SystemTap Tapset Reference Manual), and you can find the list of state numbers to names in the documentation for task_state() (on page 105 of the SystemTap Tapset Reference Manual.

Hint: The task_cpu() function takes what’s documented as a task:long. This is effectively a pointer to a task, and, in addition to the other values that are available to you, you have access to two specific task pointers in the scheduler.ctxswitch probe: prev_task and next_task.

Running your script

The way that you launch this script will be different from lab 1. Instead of opening multiple windows/shells, you will launch SystemTap with the -c command:

stap -c ./board states.stp

Make sure to look at the manual page for SystemTap (run man stap) to see what the -c option does, and how it affects the target() function in the context of the running script.

Note: The name of the file that you pass to stap needs to be a path. That is, if you only write stap -c board states.stp, SystemTap will claim that it can’t find the file board. You either need to pass a relative path to the file (as above, ./board) or an absolute path to the file (you can figure out what directory you’re in with pwd).

Testing your script

Test your script with both board.c and pi.c. These programs have very different behaviour. Are the observations you make about running these two programs consistent with what you expected to see given the description of scheduling policies/algorithms in OSTEP?