From patchwork Wed Sep 4 13:53:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konstantin Khlebnikov X-Patchwork-Id: 11130347 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BA8671395 for ; Wed, 4 Sep 2019 13:53:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 865BE2341F for ; Wed, 4 Sep 2019 13:53:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="GSPWrkxb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 865BE2341F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E42066B000A; Wed, 4 Sep 2019 09:53:20 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id DCC196B000C; Wed, 4 Sep 2019 09:53:20 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C68086B000D; Wed, 4 Sep 2019 09:53:20 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id A0DE76B000A for ; Wed, 4 Sep 2019 09:53:20 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 0EB82998B for ; Wed, 4 Sep 2019 13:53:20 +0000 (UTC) X-FDA: 75897380160.25.songs70_1d07f06d7e63b X-Spam-Summary: 2,0,0,7d44a4df8d67efe9,d41d8cd98f00b204,khlebnikov@yandex-team.ru,::linux-kernel@vger.kernel.org:cgroups@vger.kernel.org:mhocko@suse.com:guro@fb.com:hannes@cmpxchg.org,RULES_HIT:41:152:355:379:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:1801:2393:2553:2559:2562:2693:2914:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4605:5007:6119:6261:6653:7875:7903:7974:8603:8660:8829:8957:9207:10004:10400:10450:10455:11026:11232:11473:11658:11914:12043:12297:12438:12517:12519:12555:12679:12760:12986:13148:13230:14096:14097:14181:14394:14687:14721:14922:19904:19999:21080:21222:21450:21451:21627:21795:30051:30054:30090,0,RBL:95.108.205.193:@yandex-team.ru:.lbl8.mailshell.net-62.2.3.100 66.100.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:1,LUA_SUMMARY:none X-HE-Tag: songs70_1d07f06d7e63b X-Filterd-Recvd-Size: 4800 Received: from forwardcorp1o.mail.yandex.net (forwardcorp1o.mail.yandex.net [95.108.205.193]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Sep 2019 13:53:19 +0000 (UTC) Received: from mxbackcorp1g.mail.yandex.net (mxbackcorp1g.mail.yandex.net [IPv6:2a02:6b8:0:1402::301]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id 4B2552E1B27; Wed, 4 Sep 2019 16:53:17 +0300 (MSK) Received: from smtpcorp1o.mail.yandex.net (smtpcorp1o.mail.yandex.net [2a02:6b8:0:1a2d::30]) by mxbackcorp1g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id TeRZbfHkYc-rGCqWrsv; Wed, 04 Sep 2019 16:53:17 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1567605197; bh=VxqnRtVdrBaKi5aYplTaVoduEG2sU6I/aWRnOnGbhO0=; h=In-Reply-To:Message-ID:References:Date:To:From:Subject:Cc; b=GSPWrkxb670ZPlW2DXL3qhwLT3Fup/xjYJ6vwF3G2Qai3g/SrzfIXNRgAwcvm0/Ti A18Dsr8a3PSVV8YxTvU8h7v8qAAvrmvPWi7QMygAqAkIhFT6IgIc0TxiiBlmoiaTNw PD0QCzoazULCxKs2DLAfXEzQCa30nglUzzQFLjvs= Authentication-Results: mxbackcorp1g.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:40c:c142:79c2:9d86:677a]) by smtpcorp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 6QVRv2aEFs-rGf4XfSK; Wed, 04 Sep 2019 16:53:16 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: [PATCH v1 4/7] mm/mlock: recharge memory accounting to first mlock user From: Konstantin Khlebnikov To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Cc: Michal Hocko , Roman Gushchin , Johannes Weiner Date: Wed, 04 Sep 2019 16:53:16 +0300 Message-ID: <156760519646.6560.5927254238728419748.stgit@buzz> In-Reply-To: <156760509382.6560.17364256340940314860.stgit@buzz> References: <156760509382.6560.17364256340940314860.stgit@buzz> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Currently mlock keeps pages in cgroups where they were accounted. This way one container could affect another if they share file cache. Typical case is writing (downloading) file in one container and then locking in another. After that first container cannot get rid of file. This patch recharges accounting to cgroup which owns mm for mlock vma. Recharging happens at first mlock, when PageMlocked is set. Mlock moves pages into unevictable LRU under pte lock thus in this place we cannot call reclaimer. To keep things simple just charge using force. After that memory usage temporary could be higher than limit but cgroup will reclaim memory later or trigger oom, which is valid outcome when somebody mlock too much. Signed-off-by: Konstantin Khlebnikov --- Documentation/admin-guide/cgroup-v1/memory.rst | 5 +++++ mm/mlock.c | 9 ++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 41bdc038dad9..4c79e5a9153b 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -220,6 +220,11 @@ the cgroup that brought it in -- this will happen on memory pressure). But see section 8.2: when moving a task to another cgroup, its pages may be recharged to the new cgroup, if move_charge_at_immigrate has been chosen. +Locking pages in memory with mlock() or mmap(MAP_LOCKED) recharges pages +into current memory cgroup. This recharge ignores memory limit thus memory +usage could temporary become higher than limit. After that any allocation +will reclaim memory down to limit or trigger oom if mlock size does not fit. + Exception: If CONFIG_MEMCG_SWAP is not used. When you do swapoff and make swapped-out pages of shmem(tmpfs) to be backed into memory in force, charges for pages are accounted against the diff --git a/mm/mlock.c b/mm/mlock.c index 73d477aaa411..68f068711203 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -97,8 +97,15 @@ void mlock_vma_page(struct vm_area_struct *vma, struct page *page) mod_zone_page_state(page_zone(page), NR_MLOCK, hpage_nr_pages(page)); count_vm_event(UNEVICTABLE_PGMLOCKED); - if (!isolate_lru_page(page)) + if (!isolate_lru_page(page)) { + /* + * Force memory recharge to mlock user. Cannot + * reclaim memory because called under pte lock. + */ + mem_cgroup_try_recharge(page, vma->vm_mm, + GFP_NOWAIT | __GFP_NOFAIL); putback_lru_page(page); + } } }