Posts
162
Following
27
Followers
324

@andree Actually, the issue is the opposite. What we have is a one size scheduler that fits everyone. But I think it’s more like all season tires. Where they suck in all seasons, but suck equally. The issue I found most frustrating with making changes to the scheduler, is that you may make a change that helps your specific workload, but will cause regressions in someone else’s workload, and your change much be reverted. Now you are stuck with either our of tree patches, or your workflow suffers.

I’m not a big fan of BPF, but I have been a long advocate for pluggable schedulers. My preference would have been true kernel modules, or config options (like file systems), as BPF programs are IMO harder to collaborate on.

1
0
1

Steven Rostedt

Edited 5 days ago
"And you get a scheduler, and you get a scheduler, and you get a scheduler"

[ stolen from a colleague ]

3
6
9

Steven Rostedt

Edited 5 days ago
0
4
3

Linux Plumbers 2024 has accepted 9 Microconferences! But we had 26 submissions for 18 slots! What to do with that? Read about it here: https://lpc.events/blog/current/index.php/2024/05/03/awesome-amount-of-microconference-submissions/

0
7
7

@jann @vbabka @T_X @kees Note, the CONFIG_PSTORE_FTRACE just adds hooks into the ftrace infrastructure to have it write into the pstore. What I did is different. Here you give the ftrace infrastructure a block of memory (starting address and size), and it will map its ring buffer on top of that. There’s no hooks. All functionality of ftrace will write into the that range of memory.

Yes, if pstore can give me a block of memory, I’ll use it. Really, the code I wrote just lets you use any block of memory. How I get that block of memory is part 2 of his story. 😉

0
0
3
@vbabka @T_X there is a printk trace event that writes all the printk output to the tracing ring buffer. Enable that event, and you have that feature. 😁
0
0
2
Just posted a proof of concept that allows you to read a trace after a reboot, including a kernel crash!
https://lore.kernel.org/lkml/20240306015910.766510873@goodmis.org/
2
10
25
0
3
14

@kernellogger But what if that “crazy” operation is actually documented in a man page?

 mkdir /tmp/tracing
# cp -r /sys/kernel/tracing/events /tmp/tracing
# exit
$ trace-cmd sqlhist -t /tmp/tracing ...

https://trace-cmd.org/Documentation/trace-cmd/trace-cmd-sqlhist.1.html

1
0
0

Doing some testing against a change; I ran two traces. Recording the trace before applying the patch as trace-b.dat and then calling the trace file after applying the patch as trace-a.dat. Then doing an ls trace*.dat I have:

trace-a.dat
trace-b.dat

And it looks like trace-a.dat should come before trace-b.dat. I’m so confused! 😛

1
0
1
Looks like a lot of people are still without power in Portland. Linus gets a surprise vacation during the merge window 🫤
1
2
5

I’m being “schooled” by Al Viro on how dcache, inodes, and files work internally.

This is a very interesting read that I recommend anyone that wants to understand VFS better should look at.

And don’t just stop at that email, the thread goes on. Very educational. Hopefully someone smarter than I can add this to the VFS documentation in the kernel 😉

1
22
27

Allow ring buffer to have bigger sub buffers

Hmm, that subject line may not have been appropriate. 🤔

0
0
0

@gregkh @vbabka @qyousef Well the problem is that it still requires manual effort to even include the clean up patch. The point I was making is that if a clean up patch causes a backport to fail, I still have to look at why instead of it just nicely being pulled in by the stable tag. The clean up in question, touched much more than the areas that failed, so it too may not backport properly.

0
0
0

@qyousef @vbabka Which, BTW is exactly what happened here! 😛

0
0
1

@qyousef @vbabka Exactly. If you do clean ups in the code that you are modifying then all is OK, because the modifications you are making will cause the backports to fail anyway, so the clean ups do not cause extra work. But if you just have random clean ups in code that hasn’t changed in years, if a bug in that code is found, then the backports are going to be a pain fixing all previous version before the “cleanup”.

1
0
2

@vbabka @qyousef I just wasted over an hour fixing patches that should have gone back automatically without my involvement. I don’t think 1/0 vs true/false is worth it. Note, I’m doing this on my own time, where I have other things I rather be doing.

1
0
0

@qyousef Although, I just hit another patch that did not backport properly because of that change 😛 This means I’m going to NACK all clean up changes from now on, citing that it breaks backports.

1
0
1

@qyousef false better than 0 is more for understanding that the value is a boolean an not to be taken as numeric. Sometimes that makes it easier to understand the logic. I’ve been trying to use boolean in those cases as well. This also is a requirement if you ever plan on using Rust 😉

1
0
0

I don’t mind clean up patches, but this is the reason a lot of Linux kernel maintainers frown on them.

https://lore.kernel.org/all/2023120938-unclamped-fleshy-688e@gregkh/

This failure is because of a clean up patch that converted everything to “bool” where it could be:

https://lore.kernel.org/all/20230305155532.5549-3-ubizjak@gmail.com/T/#u

If I had not accepted that clean up, this backport would have been pulled in automatically with no extra work from myself. But because I added that clean up, I now have to fix this for every stable release before that clean up 🙁

1
0
2
Show older