From patchwork Tue Oct 2 11:28:51 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 10623405 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 38A5D1515 for ; Tue, 2 Oct 2018 11:29:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2464428829 for ; Tue, 2 Oct 2018 11:29:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 189652882E; Tue, 2 Oct 2018 11:29:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8796228829 for ; Tue, 2 Oct 2018 11:28:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A04CC6B0006; Tue, 2 Oct 2018 07:28:58 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 9B24C6B0007; Tue, 2 Oct 2018 07:28:58 -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 87B7D6B0008; Tue, 2 Oct 2018 07:28:58 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by kanga.kvack.org (Postfix) with ESMTP id 29EE36B0006 for ; Tue, 2 Oct 2018 07:28:58 -0400 (EDT) Received: by mail-ed1-f72.google.com with SMTP id l18-v6so1070914edq.19 for ; Tue, 02 Oct 2018 04:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from:to :cc:subject:message-id:references:mime-version:content-disposition :in-reply-to:user-agent; bh=yPU3Akyh8rW0R2TKf/8bODhaNmVeLV7DoYy6oJU7/tE=; b=KJPT+KHUl5WyuwekaKHKh5HWnSxlQnRskDYi/TTYmqLyolLVSToAh3SXBekWjKtVnO b8MUE7qrga7gpUCEKeEUCsvuTuCiNALzLvwBQ4YAG6mIrYl7REKwe3GxrH3O110FfYLv UsS9XZufKYeuB36XhxJ9Q9FxZQP9nvjs5WQI5TnBtJcGlbZTwfGN0fZbzfaIY2MLpGC/ i5EWqMPC4V+gVbVUI8VfumS1wYwVWKXsylFpSWjEJ+Kjm9aNr5L7P4rQ7miWb1huvrrz pzBwskNhnGEKs++yE7F1cewg24L9IK3EaQ0Uknyo1/AYJq7XI6Qq0PgoFBp14NuLxM0y cEmQ== X-Original-Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org X-Gm-Message-State: ABuFfog5vBdl1+ruqTegFTbxvSToQr+RJyu20bkX7UhzkuyRlDej3/hD +uBlfivruSO7Jlt8or1vv1NGgyfcFFu4KCsVPv77y/WGfE4KpCUD60lzkNxd+N7+QGmhPzq/DWs P5lEuQhw6tMyFFtFddbaczV+3VPLT33bjCUPUjWghTO0EKR8c9JdcOcu+8SYE718= X-Received: by 2002:a17:906:1b03:: with SMTP id o3-v6mr19028560ejg.102.1538479737624; Tue, 02 Oct 2018 04:28:57 -0700 (PDT) X-Google-Smtp-Source: ACcGV62Gx7SGCjuyoI39hCWvaD/p48Tr6m0FIoWVZ0BLr6STN/E6pbmPdz6RhWMRV+AXdLCvgQeB X-Received: by 2002:a17:906:1b03:: with SMTP id o3-v6mr19028499ejg.102.1538479736557; Tue, 02 Oct 2018 04:28:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538479736; cv=none; d=google.com; s=arc-20160816; b=UiSmKskSM1fhd4/gL5sTZqRjnqXHCoK1gYbMj1zH+9dooF9pEXqb1x++u5wKg0EwKL 83C1JEBjuhy9QBCiyPeeP14Dmawk7HgfifrMn9rQ+bb1ajiK0QFKfTIuaPsxV6pJhh5B TxZ3m6naJMIplx4ItBAry71NBD+rGMqD7b9LkG8mbMJZD7z0aTxtu1yRLDccxlXZY5DE cvz+L5CD+U6pblU8GHB6u36kkutspxTtzcIZll9iQjgpO4tpumv70DFjf1zIrOMeR36z Qlxz/uyC18Ws8kjapAoTrZvdsO8GOn3ax20Bom2lv8Ei+/c1O7MnzG+wLS1GAcijJ3Ns ti4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date; bh=yPU3Akyh8rW0R2TKf/8bODhaNmVeLV7DoYy6oJU7/tE=; b=RH7jLpGdeKbNOcLd1/mJYT8tWYk+DtG9i3eE0mgkO70fFmn89CbOjJDGLbEuuT+YPP UXdV9QkvO8tA6OqPEidysKWia9Y5+YuOsjt0V9cqE3wyjyre4vVGG6xq6Nf+JkArhNxZ scfR+pM4VZ2OsAC2/m6EWBEuof10Cy6RwvuG6qV1hMxIoaoEzPDU/5f6aRf9Z28lfxUk af5c+5lW9G7EvBD7tSzdEDqnxyjfewjrp8DH7bSneXt6gH4Kb6jIdNkId2m3tDrZvuG4 57pqo7oniw9+gaB72SWGajnKO4jnwp++eVHLS2Guj4oMC1YmU+/yNFr6oASG3I4J6Nmg pN4g== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id w5-v6si1879104eds.451.2018.10.02.04.28.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 04:28:56 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning mhocko@kernel.org does not designate 195.135.220.15 as permitted sender) smtp.mailfrom=mhocko@kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 18E8CAFC1; Tue, 2 Oct 2018 11:28:56 +0000 (UTC) Date: Tue, 2 Oct 2018 13:28:51 +0200 From: Michal Hocko To: Andrew Morton Cc: David Rientjes , Vlastimil Babka , Alexey Dobriyan , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org Subject: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc Message-ID: <20181002112851.GP18290@dhcp22.suse.cz> References: <20180924195603.GJ18685@dhcp22.suse.cz> <20180924200258.GK18685@dhcp22.suse.cz> <0aa3eb55-82c0-eba3-b12c-2ba22e052a8e@suse.cz> <20180925202959.GY18685@dhcp22.suse.cz> <20180925150406.872aab9f4f945193e5915d69@linux-foundation.org> <20180926060624.GA18685@dhcp22.suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180926060624.GA18685@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) 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: X-Virus-Scanned: ClamAV using ClamSMTP On Wed 26-09-18 08:06:24, Michal Hocko wrote: > On Tue 25-09-18 15:04:06, Andrew Morton wrote: > > On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes wrote: > > > > > > > It is also used in > > > > > automated testing to ensure that vmas get disabled for thp appropriately > > > > > and we used "nh" since that is how PR_SET_THP_DISABLE previously enforced > > > > > this, and those tests now break. > > > > > > > > This sounds like a bit of an abuse to me. It shows how an internal > > > > implementation detail leaks out to the userspace which is something we > > > > should try to avoid. > > > > > > > > > > Well, it's already how this has worked for years before commit > > > 1860033237d4 broke it. Changing the implementation in the kernel is fine > > > as long as you don't break userspace who relies on what is exported to it > > > and is the only way to determine if MADV_NOHUGEPAGE is preventing it from > > > being backed by hugepages. > > > > 1860033237d4 was over a year ago so perhaps we don't need to be > > too worried about restoring the old interface. In which case > > we have an opportunity to make improvements such as that suggested > > by Michal? > > Yeah, can we add a way to export PR_SET_THP_DISABLE to userspace > somehow? E.g. /proc//status. It is a process wide thing so > reporting it per VMA sounds strange at best. So how about this? (not tested yet but it should be pretty straightforward) --- From 048b29102de326900b54cce78b614345cd77a230 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Tue, 2 Oct 2018 10:53:48 +0200 Subject: [PATCH] mm, proc: report PR_SET_THP_DISABLE in proc David Rientjes has reported that 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active") has changed the way how we report THPable VMAs to the userspace. Their monitoring tool is triggering false alarms on PR_SET_THP_DISABLE tasks because it considers an insufficient THP usage as a memory fragmentation resp. memory pressure issue. Before the said commit each newly created VMA inherited VM_NOHUGEPAGE flag and that got exposed to the userspace via /proc//smaps file. This implementation had its downsides as explained in the commit message but it is true that the userspace doesn't have any means to query for the process wide THP enabled/disabled status. PR_SET_THP_DISABLE is a process wide flag so it makes a lot of sense to export in the process wide context rather than per-vma. Introduce a new field to /proc//status which export this status. If PR_SET_THP_DISABLE is used the it reports false same as when the THP is not compiled in. It doesn't consider the global THP status because we already export that information via sysfs Fixes: 1860033237d4 ("mm: make PR_SET_THP_DISABLE immediately active") Signed-off-by: Michal Hocko --- Documentation/filesystems/proc.txt | 3 +++ fs/proc/array.c | 10 ++++++++++ 2 files changed, 13 insertions(+) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 22b4b00dee31..bafa5cb1685a 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -182,6 +182,7 @@ For example, to get the status information of a process, all you have to do is VmSwap: 0 kB HugetlbPages: 0 kB CoreDumping: 0 + THP_enabled: 1 Threads: 1 SigQ: 0/28578 SigPnd: 0000000000000000 @@ -256,6 +257,8 @@ Table 1-2: Contents of the status files (as of 4.8) HugetlbPages size of hugetlb memory portions CoreDumping process's memory is currently being dumped (killing the process may lead to a corrupted core) + THP_enabled process is allowed to use THP (returns 0 when + PR_SET_THP_DISABLE is set on the process Threads number of threads SigQ number of signals queued/max. number for queue SigPnd bitmap of pending signals for the thread diff --git a/fs/proc/array.c b/fs/proc/array.c index 0ceb3b6b37e7..9d428d5a0ac8 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -392,6 +392,15 @@ static inline void task_core_dumping(struct seq_file *m, struct mm_struct *mm) seq_putc(m, '\n'); } +static inline void task_thp_status(struct seq_file *m, struct mm_struct *mm) +{ + bool thp_enabled = IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE); + + if (thp_enabled) + thp_enabled = !test_bit(MMF_DISABLE_THP, &mm->flags); + seq_printf(m, "THP_enabled:\t%d\n", thp_enabled); +} + int proc_pid_status(struct seq_file *m, struct pid_namespace *ns, struct pid *pid, struct task_struct *task) { @@ -406,6 +415,7 @@ int proc_pid_status(struct seq_file *m, struct pid_namespace *ns, if (mm) { task_mem(m, mm); task_core_dumping(m, mm); + task_thp_status(m, mm); mmput(mm); } task_sig(m, task);