Received: by 10.223.164.202 with SMTP id h10csp599735wrb; Fri, 17 Nov 2017 05:49:58 -0800 (PST) X-Google-Smtp-Source: AGs4zMbSynkL3CmatelnWHXADlDE96ODi+nK4Ym/zeQTB7N4eTVWbnfUD1C1E4oA6JJlWgTI7jVE X-Received: by 10.99.108.70 with SMTP id h67mr5141580pgc.218.1510926598572; Fri, 17 Nov 2017 05:49:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510926598; cv=none; d=google.com; s=arc-20160816; b=fqZCrOM/CNGMEDCSkaEgJo3DzoGuuME9qzK7gDd7TSUpsBQHMz+2m8XOf1cyTBQakG rQQ0SXK4KatgA36gEKQP86ByPUZ+NDz07wXzIEat8h+d1jaOOX+IcZTQ6DLsa7wKE4wk PoTAK53NikXIz7mvv15huRbir7ZSi31n+CjG4wCbeKX0Wlbo3SrFhHVMlwNCXEelgb3W 36C2ph7meGX3I8fF/OWia7lEpnGwwwNGDpPWOD9dIfHBZTHaMWZ9c35LylXw+bvIrc3H HQUYwK8CrRJdfK/iZvzGqje6d4Gm7j69Z2VfjPJ+qhFRMHXFQJ+cp9KxuBoW5VACcUjX 0pgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=t8espyoqo1H6bJKdM7AhLPKa4NvwvBvBKMmlD4f7YIk=; b=YvrA7f3QlgU+1EA7LZ7+wLK4ZbzCxBG1RYo/ZwwuE9qltnKhlDv02FxiAoojMme7/8 mkhbHer+TJwRUzVb4Z7oqu0cFF6XIIGeJdjdkI/D2Ut3f39FZdCAEELiJliHR5ew96oQ dfwviP1yon9i+L9Clwf7rs1hs27uV4XPUK0iVJrqbWCJuaO2W6dnWpxsr+vmC1unvyb5 yRm7IOMrFE9SUIvg2ze+vcc7maMH1cDqIp4G+PCVyGJzzGJgkGQaLcFhtcNePUL7ur7F PT3ozZqyddZ71oykNjcL5FNmQhUzki7zRpHfWw0rApnskFc40hkfe2k0muu5ORvDd1vA AoPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VayGPMBm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k3si2723131pgc.747.2017.11.17.05.49.45; Fri, 17 Nov 2017 05:49:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VayGPMBm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933759AbdKQGl5 (ORCPT + 91 others); Fri, 17 Nov 2017 01:41:57 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:38538 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933696AbdKQGlr (ORCPT ); Fri, 17 Nov 2017 01:41:47 -0500 Received: by mail-it0-f65.google.com with SMTP id n134so2938272itg.3; Thu, 16 Nov 2017 22:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t8espyoqo1H6bJKdM7AhLPKa4NvwvBvBKMmlD4f7YIk=; b=VayGPMBmHxIvE6SeBRQXRO88XRECUQofIRq1Ng6KRSPOcLR9qIYjGngAuKuIUHIwMg 9CrQTT5kCqKBj8d83SIPY+4qqW9UWfP3eoh9BAaDzWnE0CW8ntgAW+3h0fwcFH+bT9IC 8AQHDyfrODL/ogqJ5Kvskq3EAng3XJMvZCGXY1hPQ7PsMLHTDheKI73PeqZaRXnqZYyD Sd6Nx0/pgASOdsc/4n/D2td5m3w7CNEvosmI+9NX+pgal/hs6n8CqdPMPcamwlyq8UZr 8GEAph78N3V2NqZsQuUcvDAuyyiM+wI42mDbajfle6T5Dvv6/3mBTxLVWKFyKKUU/c1p Q9LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t8espyoqo1H6bJKdM7AhLPKa4NvwvBvBKMmlD4f7YIk=; b=OeMhpuWkL3se1dxukF9kkj4J/jcTlj4nLMLgO7V4PEGTlcXBHfYrA/Hi2g+5fialQE JoUqQ7D/FtDzYE4/9SXd1oxhVG+EKxSyc/239Mkd7OE0GJbUJ/9M8Vj9CnevBF8tt5eD Bp1fnMls0zGn9isAu5+RlL22Dw44qUB8DN2cDRnRKsnuRtrf3FcacWKHZlJcrJkTGeDe SwbZhPuDHS/cz4Xcj/SKAMvPai/Rs/pG/vlqfX3z0nSjimrXAx94/gCYqA0rtd9RdKcM P35UjsS3OnbBaUaHyqwsZK6FJ4kUG1didDslYs/BCB6rlfUR+R3IEpksjy+SoaHULZqd JA5Q== X-Gm-Message-State: AJaThX6hiAwRtLnN1wM9qnIHTOw/fXCTqCEn4Fws1IKDwIylUNPGrMlO elbRMzJ91krZtkD5t46hxVNDhZFADXsEy71Ip6Y= X-Received: by 10.36.25.2 with SMTP id b2mr5698977itb.31.1510900906981; Thu, 16 Nov 2017 22:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.160.73 with HTTP; Thu, 16 Nov 2017 22:41:46 -0800 (PST) In-Reply-To: References: <1510888199-5886-1-git-send-email-laoar.shao@gmail.com> From: Yafang Shao Date: Fri, 17 Nov 2017 14:41:46 +0800 Message-ID: Subject: Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit To: Shakeel Butt Cc: Andrew Morton , Johannes Weiner , Vladimir Davydov , Michal Hocko , Tejun Heo , Roman Gushchin , khlebnikov@yandex-team.ru, mka@chromium.org, Hugh Dickins , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-11-17 12:43 GMT+08:00 Shakeel Butt : > On Thu, Nov 16, 2017 at 7:09 PM, Yafang Shao wrote: >> Currently the default tmpfs size is totalram_pages / 2 if mount tmpfs >> without "-o size=XXX". >> When we mount tmpfs in a container(i.e. docker), it is also >> totalram_pages / 2 regardless of the memory limit on this container. >> That may easily cause OOM if tmpfs occupied too much memory when swap is >> off. >> So when we mount tmpfs in a memcg, the default size should be limited by >> the memcg memory.limit. >> > > The pages of the tmpfs files are charged to the memcg of allocators > which can be in memcg different from the memcg in which the mount > operation happened. Yes. But the issue is tmpfs files contributed to memory.usage_in_bytes should be limited. Let me take an example. The physical memory size is 1G, and we create a memory cgroup then set the memory.limit_in_bytes of it to 256M. Then in this memory cgroup we do bellow test: 1. mount -t tmpfs tmpfs /mount the size of which will be 1G / 2 by default. 2. write files into this tmpfs as the limit of this memory cgroup is 256M while the size of tmpfs is 512M, these files will occupy the while memory in this cgroup and finally out of memory. > So, tying the size of a tmpfs mount where it was > mounted does not make much sense. > > Also mount operation which requires CAP_SYS_ADMIN, is usually > performed by node controller (or job loader) which don't necessarily > run in the memcg of the actual job. > >> Signed-off-by: Yafang Shao >> --- >> include/linux/memcontrol.h | 1 + >> mm/memcontrol.c | 2 +- >> mm/shmem.c | 20 +++++++++++++++++++- >> 3 files changed, 21 insertions(+), 2 deletions(-) >> >> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h >> index 69966c4..79c6709 100644 >> --- a/include/linux/memcontrol.h >> +++ b/include/linux/memcontrol.h >> @@ -265,6 +265,7 @@ struct mem_cgroup { >> /* WARNING: nodeinfo must be the last member here */ >> }; >> >> +extern struct mutex memcg_limit_mutex; >> extern struct mem_cgroup *root_mem_cgroup; >> >> static inline bool mem_cgroup_disabled(void) >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index 661f046..ad32f3c 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2464,7 +2464,7 @@ static inline int mem_cgroup_move_swap_account(swp_entry_t entry, >> } >> #endif >> >> -static DEFINE_MUTEX(memcg_limit_mutex); >> +DEFINE_MUTEX(memcg_limit_mutex); > > This mutex is only needed for updating the limit. > Thanks for explaination :) >> >> static int mem_cgroup_resize_limit(struct mem_cgroup *memcg, >> unsigned long limit) >> diff --git a/mm/shmem.c b/mm/shmem.c >> index 07a1d22..1c320dd 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -35,6 +35,7 @@ >> #include >> #include >> #include >> +#include >> >> #include /* for arch/microblaze update_mmu_cache() */ >> >> @@ -108,7 +109,24 @@ struct shmem_falloc { >> #ifdef CONFIG_TMPFS >> static unsigned long shmem_default_max_blocks(void) >> { >> - return totalram_pages / 2; >> + unsigned long size; >> + >> +#ifdef CONFIG_MEMCG >> + struct mem_cgroup *memcg = mem_cgroup_from_task(current); >> + >> + if (memcg == NULL || memcg == root_mem_cgroup) >> + size = totalram_pages / 2; >> + else { >> + mutex_lock(&memcg_limit_mutex); >> + size = memcg->memory.limit > totalram_pages ? >> + totalram_pages / 2 : memcg->memory.limit / 2; >> + mutex_unlock(&memcg_limit_mutex); >> + } >> +#else >> + size = totalram_pages / 2; >> +#endif >> + >> + return size; >> } >> >> static unsigned long shmem_default_max_inodes(void) >> -- >> 1.8.3.1 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe cgroups" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html From 1584308421663399711@xxx Fri Nov 17 10:24:11 +0000 2017 X-GM-THRID: 1584307723039976913 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread