Thread (31 messages) 31 messages, 4 authors, 2015-09-04

Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled

From: Vladimir Davydov <hidden>
Date: 2015-08-31 14:30:25
Also in: lkml

On Mon, Aug 31, 2015 at 09:43:35AM -0400, Tejun Heo wrote:
On Mon, Aug 31, 2015 at 03:24:15PM +0200, Michal Hocko wrote:
quoted
Right but isn't that what the caller explicitly asked for? Why should we
ignore that for kmem accounting? It seems like a fix at a wrong layer to
me. Either we should start failing GFP_NOWAIT charges when we are above
high wmark or deploy an additional catchup mechanism as suggested by
Tejun. I like the later more because it allows to better handle GFP_NOFS
requests as well and there are many sources of these from kmem paths.
Yeah, this is beginning to look like we're trying to solve the problem
at the wrong layer.  slab/slub or whatever else should be able to use
GFP_NOWAIT in whatever frequency they want for speculative
allocations.
slab/slub can issue alloc_pages() any time with any flags they want and
it won't be accounted to memcg, because kmem is accounted at slab/slub
layer, not in buddy.

Thanks,
Vladimir

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