All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: linux-api@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [RFC PATCH 3/3] mm, proc: report PR_SET_THP_DISABLE in proc
Date: Tue, 20 Nov 2018 12:42:19 +0100	[thread overview]
Message-ID: <20181120114219.GG22247@dhcp22.suse.cz> (raw)
In-Reply-To: <20181120103515.25280-4-mhocko@kernel.org>

Damn, David somehow didn't make it to the CC list. Sorry about that.

On Tue 20-11-18 11:35:15, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> 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/<pid>/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/<pid>/status which export this status.  If
> PR_SET_THP_DISABLE is used then 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 <mhocko@suse.com>
> ---
>  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 06562bab509a..7995e9322889 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);
> -- 
> 2.19.1

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2018-11-20 11:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 10:35 [RFC PATCH 0/3] THP eligibility reporting via proc Michal Hocko
2018-11-20 10:35 ` Michal Hocko
2018-11-20 10:35 ` [RFC PATCH 1/3] mm, proc: be more verbose about unstable VMA flags in /proc/<pid>/smaps Michal Hocko
2018-11-20 10:35   ` Michal Hocko
2018-11-20 10:51   ` Jan Kara
2018-11-20 11:41     ` Michal Hocko
2018-11-21  0:01     ` David Rientjes
2018-11-21  6:56       ` Michal Hocko
2018-11-20 18:32   ` Dan Williams
2018-11-21  7:05     ` Michal Hocko
2018-11-21 18:01       ` Mike Rapoport
2018-11-21 17:54   ` Mike Rapoport
2018-11-21 17:58     ` Michal Hocko
2018-11-23 13:47   ` Vlastimil Babka
2018-11-20 10:35 ` [RFC PATCH 2/3] mm, thp, proc: report THP eligibility for each vma Michal Hocko
2018-11-20 10:35   ` Michal Hocko
2018-11-20 11:42   ` Michal Hocko
2018-11-23 15:07   ` Vlastimil Babka
2018-11-23 15:21     ` Michal Hocko
2018-11-23 15:24       ` Vlastimil Babka
2018-11-20 10:35 ` [RFC PATCH 3/3] mm, proc: report PR_SET_THP_DISABLE in proc Michal Hocko
2018-11-20 10:35   ` Michal Hocko
2018-11-20 11:42   ` Michal Hocko [this message]
2018-11-23 15:49   ` Vlastimil Babka
2018-11-27  0:33   ` William Kucharski
2018-11-27 13:17     ` Michal Hocko
2018-11-27 14:50       ` William Kucharski
2018-11-27 16:25         ` Michal Hocko
2018-11-27 16:50         ` Vlastimil Babka
2018-11-27 17:06           ` William Kucharski
2018-12-07 10:55 ` [RFC PATCH 0/3] THP eligibility reporting via proc Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181120114219.GG22247@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.