Thread (19 messages) 19 messages, 4 authors, 2015-11-11

Re: [PATCH 5/5] Account certain kmem allocations to memcg

From: Michal Hocko <hidden>
Date: 2015-11-10 13:23:24
Also in: linux-mm, lkml

On Tue 10-11-15 11:07:09, Vladimir Davydov wrote:
On Mon, Nov 09, 2015 at 03:39:55PM +0100, Michal Hocko wrote:
[...]
quoted
pipe buffers are trivial to abuse (e.g. via fd passing) so we want to
You might also mention allocations caused by select/poll, page tables,
radix_tree_node, etc. They all might be abused, but the primary purpose
of this patch set is not catching abusers, but providing reasonable
level of isolation for most normal workloads. Let's add everything above
that in separate patches.
Sure I do not have any objections against step by step approach.
 
quoted
cap those as well. The following should do the trick AFAICS.
Actually, no - you only account pipe metadata while anon pipe buffer
pages, which usually constitute most of memory consumed by a pipe, still
go unaccounted. I'm planning to make pipe accountable later.
You are right! I have missed pipe_write allocates the real page.
quoted
---
diff --git a/fs/pipe.c b/fs/pipe.c
index 8865f7963700..c4b7e8c08362 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -590,7 +590,7 @@ struct pipe_inode_info *alloc_pipe_info(void)
 
 	pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
 	if (pipe) {
-		pipe->bufs = kzalloc(sizeof(struct pipe_buffer) * PIPE_DEF_BUFFERS, GFP_KERNEL);
+		pipe->bufs = kzalloc(sizeof(struct pipe_buffer) * PIPE_DEF_BUFFERS, GFP_KERNEL | __GFP_ACCOUNT);
GFP_KERNEL | __GFP_ACCOUNT are used really often, that's why I
introduced GFP_KERNEL_ACCOUNT.
Sure that is better.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help