Re: zram OOM behavior

[Mandeep Singh Baines <msb@google.com>]

Luigi Semenzato (semenzato@google.com) wrote:
> 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?
> 

An alternative approach I was considering was to just limit the rate at
which you scan each of the LRU lists. Limit the rate to one complete
scan of the list every scan_period. This would prevent thrashing of
file and anon pages and would require no tuning. You could set scan_period
to one of the scheduler periods.

Regards,
Mandeep

> > 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>