Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752535AbbKIOkE (ORCPT ); Mon, 9 Nov 2015 09:40:04 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37634 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751553AbbKIOj6 (ORCPT ); Mon, 9 Nov 2015 09:39:58 -0500 Date: Mon, 9 Nov 2015 15:39:55 +0100 From: Michal Hocko To: Vladimir Davydov Cc: Andrew Morton , Johannes Weiner , Tejun Heo , Greg Thelen , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] Account certain kmem allocations to memcg Message-ID: <20151109143955.GF8916@dhcp22.suse.cz> References: <60b4d1631e3a302246859d6a39ac7c6d6cbf3af3.1446924358.git.vdavydov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60b4d1631e3a302246859d6a39ac7c6d6cbf3af3.1446924358.git.vdavydov@virtuozzo.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2264 Lines: 61 On Sat 07-11-15 23:07:09, Vladimir Davydov wrote: > This patch marks those kmem allocations that are known to be easily > triggered from userspace as __GFP_ACCOUNT, which makes them accounted to > memcg. For the list, see below: > > - threadinfo > - task_struct > - task_delay_info > - pid > - cred > - mm_struct > - vm_area_struct and vm_region (nommu) > - anon_vma and anon_vma_chain > - signal_struct > - sighand_struct > - fs_struct > - files_struct > - fdtable and fdtable->full_fds_bits > - dentry and external_name > - inode for all filesystems. This is the most tedious part, because > most filesystems overwrite the alloc_inode method. Looks like using > __GFP_ACCOUNT in alloc_inode is going to become a new rule, like > passing SLAB_RECLAIM_ACCOUNT on inode cache creation. I am wondering whether using a helper function to allocate an inode cache would help in that regards. It would limit __GFP_ACCOUNT penetration into fs code. pipe buffers are trivial to abuse (e.g. via fd passing) so we want to cap those as well. The following should do the trick AFAICS. --- 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); if (pipe->bufs) { init_waitqueue_head(&pipe->wait); pipe->r_counter = pipe->w_counter = 1; @@ -971,7 +971,7 @@ static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long nr_pages) if (nr_pages < pipe->nrbufs) return -EBUSY; - bufs = kcalloc(nr_pages, sizeof(*bufs), GFP_KERNEL | __GFP_NOWARN); + bufs = kcalloc(nr_pages, sizeof(*bufs), GFP_KERNEL | __GFP_NOWARN | __GFP_ACCOUNT); if (unlikely(!bufs)) return -ENOMEM; -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/