On Sat 10-12-16 14:50:34, Gerhard Wiesinger wrote: [...] > IMHO: The OOM killer should NOT kick in even on the highest workloads if > there is swap available. This is not so simple. Take a heavy swap trashing situation as an example. You still have a lot of swap space and an anonymous memory which can be swapped out but if the workload simply keeps refaulting the swapped out memory all the time then you can barely make any further progress and end up in the swap IO hell. Invoking the OOM killer in such a situation would be a relief to make the system usable again. > https://www.spinics.net/lists/linux-mm/msg113665.html > > Yeah, but I do think that "oom when you have 156MB free and 7GB > reclaimable, and haven't even tried swapping" counts as obviously > wrong. No question about this part of course. > So Linus also thinks that trying swapping is a must have. And there > always was enough swap available in my cases. Then it should swap > out/swapin all the time (which worked well in kernel 2.4/2.6 times). > > Another topic: Why does the kernel prefer to swap in/swap out instead of use > cache pages/buffers (see vmstat 1 output below)? In the vast majority cases it is quite contrary. We heavily bias page cache reclaim in favor of the anonymous memory. Have a look at get_scan_count function which determines the balance. I would need to see /proc/vmstat collected during this time period to tell you more about why the particular balance was used. [...] > With kernel 4.7./4.8 it was really reaproduceable at every dnf update. With > 4.9rc8 it has been much much better. So something must have changed, too. that is good to hear but I it would be much better to collect reclaim related data so that we can analyse what is actually going on here. > As far as I understood it the order is 2^order kB pagesize. I don't think it > makes a difference when swap is not used which order the memory allocation > request is. > > BTW: What were the commit that introduced the regression anf fixed it in > 4.9? I cannot really answer this without actually understanding what is going on here and for that I do not have the relevant data. -- Michal Hocko SUSE Labs -- 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>