lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 23 Aug 2019 02:54:55 +0100
From:   ndrw <ndrw.xf@...hazel.co.uk>
To:     Daniel Drake <drake@...lessm.com>, aros@....com
Cc:     linux-kernel@...r.kernel.org, linux@...lessm.com,
        hadess@...ess.net, hannes@...xchg.org
Subject: Re: Let's talk about the elephant in the room - the Linux kernel's
 inability to gracefully handle low memory pressure

On 20/08/2019 07:46, Daniel Drake wrote:
> To share our results so far, despite this daemon being a quick initial
> implementation, we find that it is bringing excellent results, no more memory
> pressure hangs. The system recovers in less than 30 seconds, usually in more
> like 10-15 seconds.

That's obviously a lot better than hard freezes but I wouldn't call such 
system lock-ups an excellent result. PSI-triggered OOM killer would have 
indeed been very useful as an emergency brake, and IMHO such mechanism 
should be built in the kernel and enabled by default. But in my 
experience it does a very poor job at detecting imminent freezes on 
systems without swap or with very fast swap (zram). So far, watching 
MemAvailable (like earlyoom does) is far more reliable and accurate. 
Unfortunately, there just doesn't seem to be a kernel feature that would 
reserve a user-defined amount of memory for caches.

> There's just one issue we've seen so far: a single report of psi reporting
> memory pressure on a desktop system with 4GB RAM which is only running
> the normal desktop components plus a single gmail tab in the web browser.
> psi occasionally reports high memory pressure, so then psi-monitor steps in and
> kills the browser tab, which seems erroneous.

Is it Chrome/Chromium? If so, that's a known bug 
(https://bugs.chromium.org/p/chromium/issues/detail?id=333617)

Best regards,

ndrw


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ