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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
