On Sun, 2020-07-12 at 12:46 +0200, Kevin Kofler wrote: > Neal Gompa wrote: > > There's a difference between half-baked and a roadmap of incremental > > improvement. This Change is an example of the latter. > > No, it is actually an example of deliberately implementing a simplistic > "solution" that lags behind the state of the art on the grounds that it is > "simple", i.e., dumb.
While I really don't like Neal's line of argument here, this isn't true either. EarlyOOM is not a perfect solution. If I am honest, I don't really like the solution either. But, it is a solution that 1. exists and 2. has been well tested so that one can be reasonably confident that it works well in many scenarios. > Chris Murphy literally stated "you'll see there are many more knobs in > nohang, much more jargon" as the reason not to use a smarter solution, i.e., > this is just the usual GNOME attitude of not letting the user configure > anything, which is again getting in the way of a useful solution. You need to be careful with that argument. I do agree that GNOME sometimes ends up ignoring certain use-cases or feature requests from users on the basis that they are not really useful to "most" people. Where "most" is hard to define, because there is no real evidence available. However, this is different. As far as I know, EarlyOOM's simplicity has been validated to work reasonably well. I expect that everyone would be happy to ship "nohang" or another solution, as long as there is evidence that you have found a configuration that actually behaves better. But, that is the problem. There are a lot of options to play with, and few good tests to help find the optimal settings. In the end, the added complexity and configurability will not help you, because you will not be able to show that it actually behaves considerably better overall. > (That said, I also have doubts that ANY userspace solution can reliably > solve the problems at hand. But what is sure is that EarlyOOM's approach is > too simple to be adequate. I already pointed out the ways in which it can > end up doing the wrong thing.) The optimal solution requires BOTH user space and the kernel to collaborate. And the tool to do this are cgroups. > So it is not true that EarlyOOM is the best solution that exists out there. > It is just the only one that fits the GNOME no-options design. It is true that EarlyOOM is not the best solution. But that isn't the goal here, the goal is to solve a problem. i.e. you have a number of choices: 1. Start from scratch and try to find an optimal "nohang" configuration. I doubt you even have a methodology to figure this out, and all your efforts will be worthless in a couple of years. 2. Just ignore he issue for now, and stick with the data loss scenario of a system freezing in certain situations. 3. Use EarlyOOM, which has already been extensively tested. i.e. you trade one data loss scenario (system freezes completely, user needs to turn off) with the possibility of another data loss scenario (EarlyOOM kills something unintentional). Considering I haven't see reports of EarlyOOM killing too often, this seems pretty safe (please, prove me wrong on this one). I would think that 1. is simply out of the question due to resource constraints. Which only leaves 2. and 3. as valid options. And, I do consider both valid. It is a trade-off, and I don't think that either of the two risks (system freezing vs. unintentional OOM kill) can be estimated to an extend that makes this decision trivial. Said differently, there is no fully objective way to know which choice is better. There are possible indicators (e.g. people having tested this quite a lot, bug reports should have come in by now if EarlyOOM was problematic in F32). But, if you are looking for definite prove that the risk of a regression (i.e. unintended kill) outweighs the benefit of not freezing the system in some scenarios, then you'll have a hard time. > [SNIP] Benjamin
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- email@example.com To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://firstname.lastname@example.org