From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 409CEC46475 for ; Thu, 25 Oct 2018 14:31:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 105B52083E for ; Thu, 25 Oct 2018 14:31:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 105B52083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729865AbeJYXEW (ORCPT ); Thu, 25 Oct 2018 19:04:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:45796 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730215AbeJYWvg (ORCPT ); Thu, 25 Oct 2018 18:51:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 228DBAFDF; Thu, 25 Oct 2018 14:18:37 +0000 (UTC) Date: Thu, 25 Oct 2018 16:18:35 +0200 From: Michal Hocko To: "Edgecombe, Rick P" Cc: "daniel@iogearbox.net" , "jeyu@kernel.org" , "ard.biesheuvel@linaro.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "jannh@google.com" , "keescook@chromium.org" , "arjan@linux.intel.com" , "netdev@vger.kernel.org" , "tglx@linutronix.de" , "linux-mips@linux-mips.org" , "linux-s390@vger.kernel.org" , "x86@kernel.org" , "kristen@linux.intel.com" , "Dock, Deneen T" , "catalin.marinas@arm.com" , "mingo@redhat.com" , "will.deacon@arm.com" , "kernel-hardening@lists.openwall.com" , "bp@alien8.de" , "Hansen, Dave" , "linux-arm-kernel@lists.infradead.org" , "davem@davemloft.net" , "linux-arch@vger.kernel.org" , "arnd@arndb.de" , "sparclinux@vger.kernel.org" , "alexei.starovoitov@gmail.com" Subject: Re: [PATCH RFC v3 0/3] Rlimit for module space Message-ID: <20181025141835.GS18839@dhcp22.suse.cz> References: <20181019204723.3903-1-rick.p.edgecombe@intel.com> <6b1017c450d163539d2b974657baaaf697f0a138.camel@intel.com> <20181024150706.jewcclhhh756tupn@linux-8ccs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 25-10-18 01:01:44, Edgecombe, Rick P wrote: [...] > FWIW, cgroups seems like a better solution than rlimit to me too. Maybe you all > already know, but it looks like the cgroups vmalloc charge is done in the main > page allocator and counts against the whole kernel memory limit. I am not sure I understand what you are saying but let me clarify that vmalloc memory is accounted against memory cgroup associated with the user context calling vmalloc. All you need to do is to add __GFP_ACCOUNT to the gfp mask. The only challenge here is the charged memory life cycle. When does it get deallocated? In the worst case the memory is not tight to any user context and as such it doesn't get deallocated by killing all processes which could lead to memcg limit exhaustion. > A user may want > to have a higher kernel limit than the module space size, so it seems it isn't > enough by itself and some new limit would need to be added. If there is another restriction on this memory then you are right. -- Michal Hocko SUSE Labs