Posts
195
Following
26
Followers
417

@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.

0
0
0

@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”.

0
0
0

@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.

0
0
2

@ljs @joel_linux RCU is simply broken down into three parts:

  • grace periods
  • quiescent states
  • synchronization

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.

0
2
2
@joel_linux @ljs there's no good heuristic, either you have write fair or write unfair. There's one good alternative, and you already know what that is. 😉
0
0
3
@joel_linux @ljs
It's not about performance, it's about not locking up the system. rwlocks are short and fast because they can't be preempted so new readers can still block writers. rwsems can sleep so it's much more likely to have writer starvation.
0
0
2
Happy New Year to the new force of social media!
0
0
5

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!

0
1
3

@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.

0
0
0

@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 ;-)

0
1
2

@michaelphamct @acmel

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.

1
0
2

@jose_exposito That should be the default. I’m finding that I’ll be adding lots of #[derive(...)] all over the place.

0
0
0

@vbabka OK, i got recursion working. I don’t know what went wrong before. Perhaps it detected right away that a bug in my code would do an infinite recursion and failed out. Unfortunately, it didn’t quite tell me what that infinite condition was :-(

1
0
1

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!

0
1
2

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) { ... }
0
0
1

@aissen Moves something ;-)

0
0
0

@vbabka I immediately got a “Stack overflow” and the println! only went 3 deep. Maybe it was smarter to know it would go further?

1
0
0

@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. ;-)

0
0
1

@ljs @acmel I thought that cover said SYSTEM ADMIN

0
0
2

And today I learn that Rust does not like recursive functions :-(

(In user space, I’m recursive function happy!)

1
0
1
Show older