Re: zram OOM behavior

[Luigi Semenzato <semenzato@google.com>]

On Wed, Oct 31, 2012 at 12:24 AM, Minchan Kim <minchan@kernel.org> wrote:

> AFAIRC, I recommended mem_notify instead of hacky patch when Mandeep submitted
> at the beginning. Does it have any problem?

When we introduced min_filelist_kbytes, the Chrome browser was not
prepared to take actions on low-memory notifications, so we could not
use that approach.  We still needed somehow to prevent the system from
thrashing.

A couple of years later we added a "tab discard" feature to Chrome,
which could be used to release memory in Chrome after saving the DOM
state of a tab.  At that time I noticed a similar patch from you,
which I took and slightly modified for our purposes.  I was not aware
of Anton's earlier patch then.  The basic idea of my patch is the same
as yours, but I estimate "easily reclaimable memory" differently.

I wasn't sure my patch would be of interest here, so I never posted it.

Going back to the min_filelist_kbytes patch, it doesn't seem that it's
such a bad idea to have a mechanism that prevents text page thrash.
It would be useful if the system kept working even if nobody is paying
attention to low-memory notifications.  The hacky patch sets a
threshold under which text pages are not evicted, to maintain a
reasonably-sized working set in memory.  Perhaps this threshold should
be set dynamically based on the rate of page faults due to instruction
fetches?

> AFAIK, mem_notify had a problem to notify too late so OOM kill still happens.
> Recently, Anton have been tried new low memory notifier and It should solve
> same problem and then it's thing you need.
> https://patchwork.kernel.org/patch/1625251/

Yes, part of the problem is that all these mechanisms are based on
heuristics.  Chrome tab discard is conceptually very similar to OOM
kill.  When Chrome gets a low-memory notification, it discards a tab
and then waits for about 1s before checking if it should discard more
tabs.  If other processes are allocating aggressively (for instance
after issuing commands that load multiple tabs in parallel), they will
use up memory faster than the tab discarder is releasing it.  So it's
essential to have a functioning fall-back mechanism in the kernel.

> Of course, there are further steps to merge it but I think you can help us
> with some experiments and input your voice to meet Chrome OS's goal.

I will look at Anton's notifier and see if it would meet our needs.  Thanks!

>
> Thanks.
>
> --
> Kind regards,
> Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>