Trading off safety and performance in the kernel
Trading off safety and performance in the kernel
Posted May 14, 2015 22:27 UTC (Thu) by neilbrown (subscriber, #359)In reply to: Trading off safety and performance in the kernel by marcH
Parent article: Trading off safety and performance in the kernel
I'll be more precise. The point isn't the amount of time it takes, it is the fact that it takes any time at all.
You seem to be saying that it can't take enough time to bother you, and I suspect you are correct. Len Brown, by submitting the patch, is saying that it *does* take enough time to bother him. Are you saying he is wrong?
> Power management has always been complex and does not look like it's getting simpler any time soon.
Undoubtedly true. This has no effect on whether placing a 'sys_sync' at that point in the code actually provides any benefit. At all.
> Why bother the change and disruption if it's only for 0.001%.
Laying aside for the moment that 1% of 1% is 0.01%, these numbers are meaningless.
The vast majority of users get sync called (at least) twice on suspend - once by some user-space tooling and once by the kernel. Most (possibly all) distros already do this.
So removing the the sys_sync call from suspend in the kernel is already only going to affect few of the users that your are probably thinking of as the 99.99%.
But one of the drivers for this change is, apparently, android. I think the user-base there is a little more than 0.001%.
Posted May 15, 2015 5:19 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Whatever two particular individuals experience does not matter much, can we please go back to statistics?
> Are you saying he is wrong?
I really wonder where does that come from... are you related maybe? :-)
> Undoubtedly true. This has no effect on whether placing a 'sys_sync' at that point in the code actually provides any benefit. At all.
The connection is: reliability is inversely related to complexity and users simply want their data saved before their computer susp...crashes. See various horror stories in the other comments.
> Laying aside for the moment that 1% of 1% is 0.01%,
Agreed! Let's also lay aside that 0.1% of 1% is 0.001%. And a few others?!
> these numbers are meaningless.
They're semi-random examples, but not completely meaningless. The very simple point I was trying to drive (and hoping not to have to detail) is just: the kernel is never going to please every single use case for every single user. Proof: there are practically no hardware device shipping with an totally unpatched mainline kernel. The mainline only has code that has a significant number of actual users. So I think we all agree it's all about how [un]common is this or that use case. Statistics and trade-offs.
> So removing the the sys_sync call from suspend in the kernel is already only going to affect few of the users that your are probably thinking of as the 99.99%.
Thanks for the info and also the reminder; I got distracted by the laptop stories filling almost the entire comments space.
Trading off safety and performance in the kernel
> But one of the drivers for this change is, apparently, android.