A new method of creating user space stack tracing is being developed in the kernel that does not rely on frame pointers. This method is called SFrames. SFrames is a section in the ELF executable that holds two tables that can be used to look up the current instruction pointer in the first table (via a binary search) which takes you to the second table that tells the kernel how to find the return address for the current function. Then that address can be used to lookup the return address of that function creating a stack trace.

For the kernel to have access to these tables, which live in user space, it has to be able to handle a major page fault. That is because the table may still be on disk, and to read it, it has to be read into memory via the page fault handler. There's only two locations that generic code in the kernel can know if it's safe to handle a major page fault and that is when the task is entering or exiting the kernel.

As profilers usually trigger interrupts or NMIs to get the stack trace, including the kernel stack, it must defer the reading of the SFrames until the task goes back to user space. This talk will discuss the proposed implementation, the issues with handling deferred stack traces, and other various aspects that this new feature will provide.

The Linux kernel has a mature robust tracing infrastructure. Several in fact. The focus today is not what to trace, but how to look at what has been traced.

There's several benchmarks that test the Linux kernel scheduler. Changing the scheduler algorithm can make one benchmark perform better while making another benchmark perform worse. These benchmarks only tell you how one scheduler compares to another scheduler but it does not give you any insight into why.

This session is a discussion on what analysis can be done from tracing the scheduler. This is more than just taking statistics, but looking at the flow of events as well. What tooling can be added where it measures the work flow of tasks and how the scheduler affects it. For instance, when one task wakes up another task and that task wakes up a third. Is the way the scheduler behaving causing this flow to be delayed? Can tooling show things like how migration or length of being preempted causes latency or throughput issues?

Perhaps having this analysis can help one decide what is the best scheduler algorithm for a given work flow? Come and share your ideas, and lets make Linux have the best scheduler than any other OS!