Thread (74 messages) 74 messages, 6 authors, 2017-01-13

Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.

From: Michal Hocko <mhocko@suse.com>
Date: 2016-12-12 13:00:49

On Mon 12-12-16 12:49:03, Petr Mladek wrote:
On Mon 2016-12-12 10:07:03, Michal Hocko wrote:
quoted
On Sat 10-12-16 20:24:57, Tetsuo Handa wrote:
[...]
quoted
quoted
The introduction of uncontrolled

  warn_alloc(gfp_mask, "page allocation stalls for %ums, order:%u", ...);
I am just curious that there would be so many messages.
If I get it correctly, this warning is printed
once every 10 second. Or am I wrong?
Yes it is once per 10s per allocation context. Tetsuo's test case is
generating hundreds of such allocation paths which are hitting the
warn_alloc path. So they can meet there and generate a lot of output.
Now we have __ratelimit here which should help but most probably needs
some better tunning.

I am also considering to use a per warn_alloc lock which would also help
to make the output nicer (not interleaving for parallel callers).
Well, you might want to consider using

		stall_timeout *= 2;

instead of adding the constant 10 * HZ.
This wouldn't help in the above situation.
-- 
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help