On Tue, Jan 7, 2020 at 12:08 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
On Mon, 6 Jan 2020, 18:32 Kamil Paral, <kparal(a)redhat.com> wrote:
>
> On Sun, Jan 5, 2020 at 12:43 PM Aleksandra Fedorova <alpha(a)bookwar.info>
wrote:
>>
>> I wonder, how I as a user going to be informed about the
>> earlyoom-event? I assume abrt will recognize the crash? Will it be
>> easily visible from the abrt report that it was the OOM?
>>
>> The concern is: if we enable such a service, will we get large amount
>> of vague bug reports from users who don't understand what has
>> happened. Can we make it somehow easier to debug?
>
>
> FWIW, the behavior on Android is very close to what is proposed here. If your
application exceeds the amount of available memory, it simply closes right in front of
your eyes. No explanation, nothing, it's just gone (might be different on latest
Android versions). The same thing would happen with EarlyOOM - some application would
disappear.
>
> I agree it would be nice to inform the user before or at least after. Windows can do
it - they show a notification roughly saying "Your system is running out of memory
and some application might get closed". (At least they used to in the old days, I
haven't run out of memory for a long time, and I don't know whether Windows 10
behaves the same way). But I think it should not be a stopper for the proposal as it is.
Even without the notification the user experience is improved over the default behavior.
I am not convinced that it is an improvement to be honest.
UX before: system works, I run heavy application, system starts to hang, i understand
that there is an issue, i can kill the app or reboot, which gives me clean and working
system.
UX after: system works, no visible problems. Suddenly random app disappears, no errors or
crashes reported to me. It might be that my active app is killed, then I know that smth
happened, but what if background process is killed? Maybe my messenger app?
This comparison is not accurate.
1. In the UX before case, it's unfair you're comparing to user
intervention to kill the app rather than oom-killer.
2. oom-killer reports to the journal. earlyoom reports to the journal.
They're the same.
3. Quite a lot of errors and crashes are only ever reported to the journal.
4. UX after (i.e. with earlyoom running), the system starts to hang,
you should understand there's an issue, recovery shouldn't take quite
as long but you'll still wish the system hadn't become hung up in the
first place
5. The app is quit with SIGTERM, not killed
6. kernel oom-killer can kill background processes too
I am going to keep working in my main app without noticing that I
lost something, not knowing that I need to take action. And my system now runs in a weird
state, and can stay there for days, which will lead to more weird and nonreproducible
errors later.
No different than with oom-killer, assuming you're willing to wait for
it take action. If you force power off instead, there's some chance
you're still going to do that with earlyoom because the responsivity
problem has more to do with congestion as a result of heavy swapping.
The "hang" of a system was the feedback user got from the
system that there is something wrong. Not ideal, but at least there was something. With
this feature we don't solve the issue, we remove the "bad" feedback, and we
don't provide any replacement for it making memory problem completely invisible.
Is it really a good UX?
Insofar as aggravation is definitely not good UX, I'd say for sure
it's better to reduce user aggravation. They will still experience the
hang. It just won't last quite as long, and yet it still will be too
long.
--
Chris Murphy