From patchwork Wed Oct 11 19:03:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shakeel Butt X-Patchwork-Id: 10000367 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 02F4E602BF for ; Wed, 11 Oct 2017 19:04:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E10CA1FF3E for ; Wed, 11 Oct 2017 19:04:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D533F289E8; Wed, 11 Oct 2017 19:04:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C61AD1FF3E for ; Wed, 11 Oct 2017 19:04:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752573AbdJKTEc (ORCPT ); Wed, 11 Oct 2017 15:04:32 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:53538 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbdJKTEb (ORCPT ); Wed, 11 Oct 2017 15:04:31 -0400 Received: by mail-pf0-f174.google.com with SMTP id n73so1671369pfg.10 for ; Wed, 11 Oct 2017 12:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=HhDdTKkz6yo6vOIrpPRrNIXvzUjV6tcDKOBGAghOqgc=; b=ZgjeHkZPIIC0pKdEr2sLnaf7cOIZmV/PhtA/Vswjlo/bMLMEgthi/SJCpUqACe5onb 4tS5oyWpm39aJaSg6lEFoUNHX1px0Oj1cOuvKSUHkaB++lqW4VYvb6+GfyqSDH+3jXdO HaxYiqH80TCQLPVYhXL8gSrudKwqM+q/q4/jTcJ/vCg7Pck4z7xs7ZgPxs1pvvvTSiNj G75KsbZUwHXKaerKXg+F7Nje45VmiagiBYFE8zIo9tq6sAfEVr8WNlqYwPryo157dPko 6op/exRHCiQmyQ59AOopmjlvLViofzMiA03wxrrsx4LMtLTCS8IsGhiD2ly9XFZgFDjP ZLMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=HhDdTKkz6yo6vOIrpPRrNIXvzUjV6tcDKOBGAghOqgc=; b=fbZBoCLG30e++xqg23f97jejJr+DLuYQhxHymH4ckAob/Sk2YdvaotwK6OYliAarMd Qt2d58aGzMxlPKMoaO7JzAXlCRN78tWRejh9cj1AqA8sZ0DTnelETVbDzDyc7TC5Zvmr PoxF+bRJbX+OKJvWdEit1DTALOuCz8ff0Xkkd5LQeg59prpHSR//7+Ws5wGwxNiHuHWB pdG2CWN6XcT8qzW2qis1n041zFHZAW1KrkDNQWhOs21+pTrpCtRAhGILXREzZaudGZWv tmiAR2+vg0IlkY9oA8bOg9m1B0D3Nft71ALXtu1wvSeFSH4sKvH6NqqW06o/sBTP4Blh G+cg== X-Gm-Message-State: AMCzsaUi37xfTssyHsKnV/XlbeMAkRA3t1R5HAwhfGszbkERCXdEqTZC lgg2JotdJyxceEWcYDg0FX+TOA== X-Google-Smtp-Source: AOwi7QAOP1rnU97xnNvp02SBFfjHmISwXalw6zcFNE3dXPrrdoEdx1dK3ibPyUCbMz4y8OobFJlnOA== X-Received: by 10.84.202.12 with SMTP id w12mr16501pld.358.1507748670348; Wed, 11 Oct 2017 12:04:30 -0700 (PDT) Received: from shakeelb.mtv.corp.google.com ([100.123.228.219]) by smtp.gmail.com with ESMTPSA id o10sm23596269pgq.69.2017.10.11.12.04.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Oct 2017 12:04:29 -0700 (PDT) From: Shakeel Butt To: Alexander Viro , Vladimir Davydov , Michal Hocko , Greg Thelen , Johannes Weiner Cc: Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Shakeel Butt Subject: [PATCH v2] fs, mm: account filp cache to kmemcg Date: Wed, 11 Oct 2017 12:03:59 -0700 Message-Id: <20171011190359.34926-1-shakeelb@google.com> X-Mailer: git-send-email 2.15.0.rc0.271.g36b669edcc-goog Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The allocations from filp cache can be directly triggered by user space applications. A buggy application can consume a significant amount of unaccounted system memory. Though we have not noticed such buggy applications in our production but upon close inspection, we found that a lot of machines spend very significant amount of memory on these caches. One way to limit allocations from filp cache is to set system level limit of maximum number of open files. However this limit is shared between different users on the system and one user can hog this resource. To cater that, we can charge filp to kmemcg and set the maximum limit very high and let the memory limit of each user limit the number of files they can open and indirectly limiting their allocations from filp cache. One side effect of this change is that it will allow _sysctl() to return ENOMEM and the man page of _sysctl() does not specify that. However the man page also discourages to use _sysctl() at all. Signed-off-by: Shakeel Butt --- Changelog since v1: - removed names_cache charging to kmemcg fs/file_table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/file_table.c b/fs/file_table.c index 61517f57f8ef..567888cdf7d3 100644 --- a/fs/file_table.c +++ b/fs/file_table.c @@ -312,7 +312,7 @@ void put_filp(struct file *file) void __init files_init(void) { filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0, - SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL); + SLAB_HWCACHE_ALIGN | SLAB_PANIC | SLAB_ACCOUNT, NULL); percpu_counter_init(&nr_files, 0, GFP_KERNEL); }