This shows you the differences between two versions of the page.
ep:labs:01:contents:ex2 [2019/09/22 15:25] radu.mantu |
— (current) | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== T02. [20p] Mpstat ==== | ||
- | Open {{:ep:labs:fact_rcrs.zip|fact_rcrs.zip}} and look at the code. | ||
- | |||
- | === [10p] Task A - Python recursion depth === | ||
- | Try to run the script while passing 1000 as a command line argument. Why does it crash? | ||
- | |||
- | Luckily, python allows you to both retrieve the current recursion limit //and// set a new value for it. Increase the recursion limit so that the process will never crash, regardless of input (assume that it still has a reasonable upper bound). | ||
- | |||
- | |||
- | === [10p] Task B - CPU affinity === | ||
- | Run the script again, this time passing 10000. Use **mpstat** to monitor the load on each //individual// CPU at 1s intervals. The one with close to 100% load will be the one running our script. Note that the process might be passed around from one core to another. | ||
- | |||
- | Stop the process. Use **stress** to create N-1 CPU workers, where N is the number of cores on your system. Use **taskset** to set the CPU affinity of the N-1 workers and then run the script again. You should notice that the process is scheduled on cpu0. | ||
- | |||
- | <solution -hidden> | ||
- | **Task A:** | ||
- | <code python> | ||
- | import sys | ||
- | |||
- | N = int(sys.argv[1]) | ||
- | |||
- | sys.getrecursionlimit() | ||
- | sys.setrecursionlimit(N) | ||
- | </code> | ||
- | |||
- | **Task B:** | ||
- | |||
- | Start N-1 worker threads on cpu[1] - cpu[N-1]. Leave cpu[0] unused for when we run the script. | ||
- | |||
- | <code bash> | ||
- | $ taskset 0xfe stress -c $(( $(nproc) - 1 )) | ||
- | </code> | ||
- | </solution> | ||