On Thu 15-12-16 01:36:07, Tetsuo Handa wrote:

Michal Hocko wrote:

quoted

On Wed 14-12-16 20:37:07, Tetsuo Handa wrote:

quoted

Michal Hocko wrote:

[...]

quoted

quoted

quoted

So it would be really great if you could
	1) test with the fixed throttling
	2) loglevel=4 on the kernel command line
	3) try the above with the same loglevel

ideally 1) would be sufficient and that would make the most sense from
the warn_alloc point of view. If this is 2 or 3 then we are hitting a
more generic problem and I would be quite careful to hack it around.

Thus, I don't think I can do these.

i think this would be really valuable.

OK. I tried 1) and 2). I didn't try 3) because printk() did not work as expected.

Regarding 1), it did not help. I can still see "** XXX printk messages dropped **"
( http://I-love.SAKURA.ne.jp/tmp/serial-20161215-1.txt.xz ).

So we still manage to swamp the logbuffer. The question is whether you
can still see the lockup. This is not obvious from the output to me.

Regarding 2), I can't tell whether it helped
( http://I-love.SAKURA.ne.jp/tmp/serial-20161215-2.txt.xz ).
I can no longer see "** XXX printk messages dropped **", but sometimes they stalled.
In most cases, "Out of memory: " and "Killed process" lines are printed within 0.1
second. But sometimes it took a few seconds. Less often it took longer than a minute.
There was one big stall which lasted for minutes. I changed loglevel to 7 and checked
memory information. Seems that watermark was low enough to call out_of_memory().

Isn't that what your test case essentially does though? Keep the system
in OOM continually? Some stalls are to be expected I guess, the main
question is whether there is a point with no progress at all.
-- 
Michal Hocko
SUSE Labs

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