On 10/30/2016 05:17 AM, Simon Kirby wrote: > On Tue, Oct 11, 2016 at 09:10:13AM +0200, Vlastimil Babka wrote: > >> Great indeed. Note that meanwhile the patches went to mainline so >> we'd definitely welcome testing from the rest of you who had >> originally problems with 4.7/4.8 and didn't try the linux-next >> recently. So a good point would be to test 4.9-rc1 when it's >> released. I hope you don't want to discover regressions again too >> late, in the 4.9 final release :) > > Hello! > > I have a mixed-purpose HTPCish box running MythTV, etc. that I recently > upgraded from 4.6.7 to 4.8.4. This upgrade started OOM killing of various > processes even when there is plenty (gigabytes) of memory as page cache. Hmm, that's too bad. > This is with CONFIG_COMPACTION=y, and it occurs with or without swap on. > I'm not able to confirm on 4.9-rc2 since nouveau doesn't support NV117 > and binary blob nvidia doesn't yet like the changes to get_user_pages. Please try once it starts liking the changes. Actually this kernel-interface part of the driver isn't binary blob AFAIK, so it should be possible to adapt it? > 4.8 includes "prevent premature OOM killer invocation for high order > request" which sounds like it should fix the issue, but this certainly > does not seem to be the case for me. I copied kern.log and .config here: > http://0x.ca/sim/ref/4.8.4/ Looks like the available high-order pages are only as part of the highatomic reserves. I've checked if there might be some error in the functions deciding to reclaim/compact where they would wrongly decide that these pages are available, but it seems fine to me. > I see that this is reverted in 4.9-rc and replaced with something else. > Unfortunately, I can't test this workload without the nvidia tainting, > and "git log --oneline v4.8..v4.9-rc2 mm | grep oom | wc -l" returns 13. > Is there some stuff I should cherry-pick to try? Well, there were around 10 related patches, so I would rather try to adapt the nvidia code first, if possible. In any case, it's still bad for 4.8 then. Can you send /proc/vmstat from the system with an uptime that already experienced at least one such oom? > Simon- > -- 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>