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