-
Notifications
You must be signed in to change notification settings - Fork 5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
config: Switch CONFIG_PREEMPT to CONFIG_PREEMPT_VOLUNTARY
See discussion here: #1216
- Loading branch information
1 parent
d33d029
commit 853eff4
Showing
2 changed files
with
2 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not trying to second guess you, honest...... But are you sure you want to do this without increasing HZ to 200/250/300. I suspect desktop users are not going to thank you for this, switching from full PREEMPT to VOLUNTARY without a corresponding increase in HZ from the default 100HZ.
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, doing this without a corresponding change in HZ will make latency suffer horribly. It may not seem obvious, but PREEMPT_FULL has been hiding the latency inherent in running with HZ=100 on such a small system (and doing a very good job of it I might add).
Not long after I got my hands on my first Raspberry Pi shortly after the initial production run, I tried running it with PREEMPT_NONE and HZ=100. That attempt ended when I had set /proc/sys/kernel/hung_task_timeout to 7200 (2 hours), and was still getting warnings in the kernel log about hung tasks. With PREEMPT_VOLUNTARY and HZ=100, I had to set it to 1800 (30 minutes) to get the warnings to go away. With PREEMPT_FULL and HZ=100, I still have to set it to 600 (10 minutes) to get the warnings to go away. With PREEMPT_VOLUNTARY and HZ=250, I can get by with about 450 (7.5 minutes).
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you can find a use case where something obviously goes wrong with this change, then please create a github issue describing how to reproduce.
Ideally start with clean install and type a sequence of commands and get a bad result.
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's exactly the problem though. Nothing breaks because of this from a purely software focused perspective. No application will stop working as long as you set their timeouts high enough. What breaks is usability for non computationally intensive usage (IOW, for almost everyone out there using a Pi as anything but a compute node in a cluster system).
If you actually look at either of the systems you referenced in your final comment in that thread, they don't just set PREEMPT_VOLUNTARY, they also set a higher HZ, and that's because running anything but PREEMPT_FULL on a low power system like this with HZ=100 results in horrible latency. They can afford to use PREEMPT_VOLUNTARY because they have a higher scheduler frequency, not the other way around.
As I stated in my first comment, the longest running tasks on my Pi when I got it and tested this (in that case, building software packages under Gentoo) tied up the CPU for up to 3 times as long with PREEMPT_VOLUNTARY as they did with PREEMPT_FULL when using HZ=100. The point of /proc/sys/kernel/hung_task_timeout is to warn due to tasks that are stuck in uninterruptible sleep (usually doing I/O) for longer than some threshold. In this case, with PREEMPT_FULL and HZ=100, I had tasks that were stuck doing I/O for almost 10 minutes. With PREEMPT_VOLUNTARY and HZ=100, those same tasks took almost 30 minutes to do the exact same I/O. While they were doing said I/O, the system ran extremely slow (think like using a terminal over a 1200 baud serial line), and was at times completely unresponsive.
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See if you can reproduce that with latest kernel.
We can try building, say, ffmpeg with -j4 (or higher). If we get hung_task_timeout messages with this update and not without then that will be useful evidence that either this change needs reverting, or HZ needs increasing. But we'd like a reproducible example to help make these decisions.
853eff4There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of right now, I don't have a working system to test on. Once I do, I'll be happy to try and come up with something to deomnstrate this.
That being said, I think it may be more instructive to set hung_task_warning to something lower (the default upstream is 2 minutes, I usually use 2.5 on most of my non-embedded systems), and then count how many warnings are produced. I also think it may be more instructive to build something a bit bigger than ffmpeg (webkit or firefox maybe, or possibly even llvm (although llvm may take days to finish building, a full build takes multiple hours even on fast x86 hardware)).