Received: by 10.223.164.202 with SMTP id h10csp3735477wrb; Mon, 20 Nov 2017 04:17:15 -0800 (PST) X-Google-Smtp-Source: AGs4zMaBH9TjIVdjALek39KELzyLAbTZqFXagYehFfJMBaRkfCWz9aIsHPEh5zlfKQVEN7x1RZL6 X-Received: by 10.159.216.152 with SMTP id s24mr8071591plp.46.1511180235153; Mon, 20 Nov 2017 04:17:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511180235; cv=none; d=google.com; s=arc-20160816; b=jIUxYAmMnLOpiAxxPYMT8DJApkzHbc1ocZkIvUCjOpuVOv4i5qoLnBC1WkAeECwDq9 3Thj5TCRgfibh+f1bz67Vv4A6SEC1DfZxSyL/zNkmd5w34VVIXLKH4bPhbw/71DGFU0v Jfr6sRL4eQJN1wjUTr8uWz39Gr9drJdQCtjbT7XAMPHJnisaobNOMtBsl5AarUhCvuNf 8DZpO8nqbvnBblW6tsiyYuZQGLXyxK2eDMim5wjvdiGVVb96W/3VrGxCXCrOYTJoaLbY iH8RCSlpMDYWUz54f0lAK7985N8xuU3w5SvzN2NAy3k5Myqdcw/PvOlrVQKOOPf4Ive3 ZFTQ== 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=wXPCglxoGEpp8Lx2n7x1lbY6HE5SoMmCZkQ2Wew3RZI=; b=H+xqskyqUf74ZWZa6yDtL/fI8n/pbur4qKHG1NcC7OqjsxIycRHzKXFLjIe5C+4FbV kogCazZcEROPDar0a+G2KmLXIe9evxBia2bX3AXu3f860jxComhaCxora9ZolY0Iwh3f gpYsepjGQHycKHZj1vhBZsjGMbpO0FtWvdw50Eold4L5CmPg8K9QcTa0QZr3cXjClPVA 6YmhqDTdgz5kzv7lQ1XM5nd3AwAZko2FqJuYanJpOsbJG7Bvb8l8KKdU2N4mxE5jGAIG JUhjowx+nxx4fMwmF5q3v7c0bn+AIgfxXwo4d+ssTJcH2p1nNKLELr6IbGV03EnQWWWp OLYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Wz3OCuqK; 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 q2si7899223pgp.701.2017.11.20.04.17.05; Mon, 20 Nov 2017 04:17:15 -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=Wz3OCuqK; 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 S1751214AbdKTMQT (ORCPT + 67 others); Mon, 20 Nov 2017 07:16:19 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:45171 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751021AbdKTMQR (ORCPT ); Mon, 20 Nov 2017 07:16:17 -0500 Received: by mail-io0-f196.google.com with SMTP id z74so15499435iof.12; Mon, 20 Nov 2017 04:16:16 -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=wXPCglxoGEpp8Lx2n7x1lbY6HE5SoMmCZkQ2Wew3RZI=; b=Wz3OCuqKBYgGKSuTgf1SILLCWZds+bhdQWKOcYPzpFgbTr7fyoqQE6kX7sqav1tPUm mTMD2EyCiAcCkKMd+P+Dzfx/KdopXWT2yAz61sa1VAtPQUIeecllz4/j6CWHwlsz14OC XvG+1udtK0AmQq78sjqrpZ7hDAeolDQ9frl9Wx2Q9o1fp7YmLqRzrvNzrLwZP8sz7rw7 hZHIu49QXGVJNxa3JG4Q/BahXBMOqeh7Ya4aiYwZA1iagtyE26eb7q7LJrsrfOqvk0m6 +BPi6+ZRW47Rj0aaUmexHAkVQdoBkPwVFTSJbGqfGJOy4jiBNm/4eKM2hVgRYXKIrhip ktUg== 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=wXPCglxoGEpp8Lx2n7x1lbY6HE5SoMmCZkQ2Wew3RZI=; b=mXComoPpvDXRCWnmXDn6qV8TjEYoLUz9mKPfBS4zQ1lax6wEFjx4Vflu8b8GkSWpZ4 4Oa08Cr4R5fsevG1o0irWFDCuRndfWYcsXnOtp2yS+WnljQkrNij6b0LyUlADU/Ajimf A5rcL8rmJ6oQJ6rbrIUZgQII1rGxNf12M3fsg4nbOpB6NnWtFlo/XRzd6F6zXY303p9E hb2HMe9jznN/okUjiK7s2vzE2Q8G/Venu8BsviZVn17laxFJNg92p563YrOVbaH8x29E LoPRRwuRGTxE9cp/QLkqHMWcCG4ZhFOlIeg92ypFTV8ybatfojumJFBr0dz1AUywz/0T RjGQ== X-Gm-Message-State: AJaThX4+y4mMqr3967wkPACWQ2V5BgQzPPH0RnUv9mSR3IGitZ+GmfU7 YhEDbwgrw6S9FjxRvbMBg5Ltd+q2PllGnXaIcnE= X-Received: by 10.107.130.13 with SMTP id e13mr14089809iod.212.1511180176410; Mon, 20 Nov 2017 04:16:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.160.73 with HTTP; Mon, 20 Nov 2017 04:16:15 -0800 (PST) In-Reply-To: <20171120120422.a6r4govoyxjbgp7w@dhcp22.suse.cz> References: <1510888199-5886-1-git-send-email-laoar.shao@gmail.com> <20171117155509.GA920@castle> <20171117164531.GA23745@castle> <20171120120422.a6r4govoyxjbgp7w@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 20 Nov 2017 20:16:15 +0800 Message-ID: Subject: Re: [PATCH] mm/shmem: set default tmpfs size according to memcg limit To: Michal Hocko Cc: Shakeel Butt , Roman Gushchin , Andrew Morton , Johannes Weiner , Vladimir Davydov , Tejun Heo , 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-20 20:04 GMT+08:00 Michal Hocko : > On Fri 17-11-17 09:49:54, Shakeel Butt wrote: >> On Fri, Nov 17, 2017 at 9:41 AM, Yafang Shao wrote: > [...] >> > Of couse that is the best way. >> > But we can not ensue all applications will do it. >> > That's why I introduce a proper defalut value for them. >> > >> >> I think we disagree on the how to get proper default value. Unless you >> can restrict that all the memory allocated for a tmpfs mount will be >> charged to a specific memcg, you should not just pick limit of the >> memcg of the process mounting the tmpfs to set the default of tmpfs >> mount. If you can restrict tmpfs charging to a specific memcg then the >> limit of that memcg should be used to set the default of the tmpfs >> mount. However this feature is not present in the upstream kernel at >> the moment (We have this feature in our local kernel and I am planning >> to upstream that). > > I think the whole problem is that containers pretend to be independent > while they share a non-reclaimable resource. Fix this and you will not > have a problem. I am afraid that the only real fix is to make tmpfs > private per container instance and that is something you can easily > achieve in the userspace. > Agree with you. Introduce tmpfs stat in memory cgroup, something like memory.tmpfs.limit memory.tmpfs.usage IMHO this is the best solution. Thanks Yafang From 1584586573501453531@xxx Mon Nov 20 12:05:17 +0000 2017 X-GM-THRID: 1584307723039976913 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread