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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 772E4C41621 for ; Tue, 24 Mar 2020 13:17:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E57E20936 for ; Tue, 24 Mar 2020 13:17:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E57E20936 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B9C216B0003; Tue, 24 Mar 2020 09:17:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B74486B0006; Tue, 24 Mar 2020 09:17:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB1396B0007; Tue, 24 Mar 2020 09:17:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 909F86B0003 for ; Tue, 24 Mar 2020 09:17:41 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7BEC21848A1D4 for ; Tue, 24 Mar 2020 13:17:41 +0000 (UTC) X-FDA: 76630307922.27.pest18_7d43e26f1ad25 X-HE-Tag: pest18_7d43e26f1ad25 X-Filterd-Recvd-Size: 4242 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Mar 2020 13:17:40 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id l20so3415713wmi.3 for ; Tue, 24 Mar 2020 06:17:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=MlUVdqvPsd43LNWgtTjRFWpttrWIzyOLgg7iukgREUQ=; b=lXWjTj9LIjwQw+SnvLILwG1c4HXVmkKKxOnISTY+PA/TqooHmazSnrZ5WdFlrqz1aY TXrlUIIkM1/y2JCzQo28JNFQREIfUgRBcO3uOto+aIPfGx2CjSVSHVwwecBjgKwMS/tS 6QPKSlVVTvZ4EnPdSWX3iYvY0sAcFOiv3G1fD3i++N8x97A55uXD4xgDt94+vSOaYMTT QwcHwjrDd2aIoe0Zsa36Cf6fudg/o43HVJFAuj3xm9DOYlP/dHpEX80OluARKBMdz/H8 UYyoMRxyY809A9LXa44IOQXy7ZntMSMm7MxZdDJRg5NbSKLCVDhyxtwlzOQB29hGhXfS /48g== X-Gm-Message-State: ANhLgQ2fB+4Q2fE5e0gt/jz0Qgkrwc7YL9HMUNmzphnp5E8F0sJenq9l vcYUPt/x4lAZRGqTj/zGHQU= X-Google-Smtp-Source: ADFU+vtKqW+piCwbRuCwv8vVoYUmBSFEMo/U7U+zkJo89YQxNVypxKzolTOfIZ/OJ/XmbzK62z9VLQ== X-Received: by 2002:a1c:4e0f:: with SMTP id g15mr5796918wmh.163.1585055858829; Tue, 24 Mar 2020 06:17:38 -0700 (PDT) Received: from localhost (ip-37-188-135-150.eurotel.cz. [37.188.135.150]) by smtp.gmail.com with ESMTPSA id g3sm11987687wrm.66.2020.03.24.06.17.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Mar 2020 06:17:37 -0700 (PDT) Date: Tue, 24 Mar 2020 14:17:36 +0100 From: Michal Hocko To: teawater Cc: Hui Zhu , Johannes Weiner , Vladimir Davydov , Andrew Morton , hughd@google.com, yang.shi@linux.alibaba.com, kirill@shutemov.name, dan.j.williams@intel.com, aneesh.kumar@linux.ibm.com, sean.j.christopherson@intel.com, thellstrom@vmware.com, guro@fb.com, shakeelb@google.com, chris@chrisdown.name, tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm, memcg: Add memory.transparent_hugepage_disabled Message-ID: <20200324131736.GN19542@dhcp22.suse.cz> References: <1585045916-27339-1-git-send-email-teawater@gmail.com> <20200324110034.GH19542@dhcp22.suse.cz> <816B70EC-20AD-4BB8-AD13-4F5640EBAB35@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <816B70EC-20AD-4BB8-AD13-4F5640EBAB35@linux.alibaba.com> Content-Transfer-Encoding: quoted-printable 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: On Tue 24-03-20 20:30:32, teawater wrote: >=20 >=20 > > 2020=E5=B9=B43=E6=9C=8824=E6=97=A5 19:00=EF=BC=8CMichal Hocko =E5=86=99=E9=81=93=EF=BC=9A > >=20 > > On Tue 24-03-20 18:31:56, Hui Zhu wrote: > >> /sys/kernel/mm/transparent_hugepage/enabled is the only interface to > >> control if the application can use THP in system level. > >> Sometime, we would not want an application use THP even if > >> transparent_hugepage/enabled is set to "always" or "madvise" because > >> thp may need more cpu and memory resources in some cases. > >=20 > > Could you specify that sometime by a real usecase in the memcg contex= t > > please? >=20 >=20 > Thanks for your review. >=20 > We use thp+balloon to supply more memory flexibility for vm. > https://lore.kernel.org/linux-mm/1584893097-12317-1-git-send-email-teaw= ater@gmail.com/ > This is another thread that I am working around thp+balloon. >=20 > Other applications are already deployed on these machines. The > transparent_hugepage/enabled is set to never because they used to have > a lot of THP related performance issues. And some of them may call > madvise thp with itself. If they call madvise then they clearly indicate they prefer THP regardless the cost. So I really fail to see what memcg specific tuning brings in. Could you be more specific about the usecase that cannot work with the existing THP tuning? --=20 Michal Hocko SUSE Labs