[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180926061247.GB18685@dhcp22.suse.cz>
Date: Wed, 26 Sep 2018 08:12:47 +0200
From: Michal Hocko <mhocko@...nel.org>
To: David Rientjes <rientjes@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Alexey Dobriyan <adobriyan@...il.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-api@...r.kernel.org
Subject: Re: [patch v3] mm, thp: always specify disabled vmas as nh in smaps
On Tue 25-09-18 14:50:52, David Rientjes wrote:
[...]
Let's put my general disagreement with the approach asside for a while.
If this is really the best way forward the is the implementation really
correct?
> + /*
> + * Disabling thp is possible through both MADV_NOHUGEPAGE and
> + * PR_SET_THP_DISABLE. Both historically used VM_NOHUGEPAGE. Since
> + * the introduction of MMF_DISABLE_THP, however, userspace needs the
> + * ability to detect vmas where thp is not eligible in the same manner.
> + */
> + if (vma->vm_mm && test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags)) {
> + flags &= ~VM_HUGEPAGE;
> + flags |= VM_NOHUGEPAGE;
> + }
Do we want to report all vmas nh? Shouldn't we limit that to THP-able
mappings? It seems quite strange that an application started without
PR_SET_THP_DISABLE wouldn't report nh for most mappings while it would
otherwise. Also when can we have vma->vm_mm == NULL?
> +
> seq_puts(m, "VmFlags: ");
> for (i = 0; i < BITS_PER_LONG; i++) {
> if (!mnemonics[i][0])
> continue;
> - if (vma->vm_flags & (1UL << i)) {
> + if (flags & (1UL << i)) {
> seq_putc(m, mnemonics[i][0]);
> seq_putc(m, mnemonics[i][1]);
> seq_putc(m, ' ');
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists