@hergertme as for getting that information in the kernel. If there’s an elf section for it, it shouldn’t be too hard. We are already looking into it. The idea is to flag that the task has the sframe section available, and when perf wants a trace, it will set a callback of some kind, and when the task is about to go back to user space, the section will be mapped in and call the perf callback to with the user space stacktrace.
It doesn’t matter when the user space stacktrace happens inside the kernel, it’s not going to change.
@hergertme sframe
is similar to ORC. I guess it we should take some time to do the benchmarks with and without frame pointers, on critical loads.
ORC has solved the issue for the kernel, but currently profiling user space without frame pointers is “interesting”.
@hergertme Is there a performance penalty with this?
And if sframe support becomes default (after it is accepted), then we could teach the kernel to do user space stack tracing without frame pointers.
@ljs @joel_linux RCU is simply broken down into three parts:
A quiescent state is a time or action that guarantees all grace periods that were running at the time of the synchronization have finished (but you do not care about grace periods that started after synchronization).
If a link list protected by disabling preemption, then the grace period is when preemption is disabled, and the quiescent state is when all CPUs have scheduled. So you can remove an item from the link list (where all readers must have preemption disabled to read it), and then wait for all CPUs to schedule which guarantees nothing has access to the item, where you are now free to delete it without worrying that something is reading it.
That’s the simple case. There’s more complex cases, but it all comes down to the three parts above.
I also want to state that I do not dislike Rust. This is just me ranting about things I have grown accustom to as a developer who’s main programming language has been C for over 3 decades!
@jose_exposito As Rust is really good at inferring logic, I’m surprised that it couldn’t just infer the PartialEq
trait for simple enums.
@michaelphamct @acmel I will admit that I should have just started to learn to program Rust before learning the details of its implementation. But, here I am ;-)
Yes, your book is probably better to learn the language. And I wouldn’t recommend the book I’m using to just learn to program in Rust. But I like the book, because I am interested in how rust works. I want to get as good at rust as I am with C. With most C programs, I can usually visualize what the assembly output would be. I don’t have that with Rust. And this book is useful to have in order to get that kind of understanding of the language.
@jose_exposito That should be the default. I’m finding that I’ll be adding lots of #[derive(...)]
all over the place.
Although I’m ranting here, I also want to add what I really like. The RUST_BACKTRACE
environment variable creating a nice backtrace on assert!()
errors, is really nice!
Another annoyance is that you can’t compare enums.
use self::Direction::*;
enum Direction { UP, DOWN, LEFT, RIGHT};
fn foo (dir: Direction) {
if (dir == DOWN) { ... } <<--- Error!
}
But instead you must do:
if matches!(dir, DOWN) { ... }
@acmel Rust is very much becoming dominate (especially by my employer). I like the guarantees that Rust brings, so I’m working on learning it. I bought a book on Rust, which really gets into the details of the language, but honestly, isn’t a good way to learn the language. I found that learning by example is a much better approach.
I have a non trivial program I’m writing (it was one of the programs I had to write for my interview), and I’m hitting all the fun corner cases with it. I’m trying hard to keep an open mind, but for someone that’s been programming C for over 3 decades, it’s really hard to do so. ;-)
And today I learn that Rust does not like recursive functions :-(
(In user space, I’m recursive function happy!)