Luigi Semenzato (semenzato@xxxxxxxxxx) wrote: > On Wed, Oct 31, 2012 at 12:24 AM, Minchan Kim <minchan@xxxxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>