On Sat, Jan 4, 2020 at 11:20 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Saturday, January 4, 2020 11:16:24 AM MST Michael Catanzaro wrote:
> On Fri, Jan 3, 2020 at 5:52 pm, John M. Harris Jr
> <johnmh(a)splentity.com> wrote:
> > In that case, I'd suggest waiting the 15 minutes, and then not
> > bogging down
> > your system that badly the next time. This is, really, the best
> > option.
> I'm going to suggest you stop replying in this thread if you're not
> interested in responding with productive comments.
> The user experience requirement here is "desktop should not hang for 15
> minutes when under memory pressure." Your comment indicates that it
> *should* hang, presumably to punish users for using too much memory.
> This is so absurd that I don't think you're engaging in good-faith
> discussion anymore.
Whether or not it should or should not is irrelevant. I don't see much of an
alternative than what seems to be a "hang", honestly. It has nothing to do
with something to "punish" users, it's to get the system to a state where
can `sync` and reboot.
The point of this feature proposal is precisely to get the system into
a state where they can save their work and do a proper reboot. It's
safer, less esoteric, and more reliable than sysrq+b.
It cannot become a user's burden to know the kernel is still doing
something, when there's zero feedback and zero control. When will the
system recover on its own? An hour? A day? A week? I can tell you for
sure in my test case, it was consistently stuck for > 30 minutes. I
let it go that long, many times, only to demonstrate it's not a
temporary hang, and users are acting rationally to force power off.