Re: More OOM problems

[Vlastimil Babka <vbabka@suse.cz>]

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