All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Muchun Song <songmuchun@bytedance.com>,
	corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, viro@zeniv.linux.org.uk,
	akpm@linux-foundation.org, paulmck@kernel.org,
	mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com,
	rdunlap@infradead.org, oneukum@suse.com,
	anshuman.khandual@arm.com, jroedel@suse.de,
	almasrymina@google.com, rientjes@google.com, willy@infradead.org,
	mhocko@suse.com, song.bao.hua@hisilicon.com, david@redhat.com,
	duanxiongchun@bytedance.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v9 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page
Date: Wed, 16 Dec 2020 14:49:36 -0800	[thread overview]
Message-ID: <49f6a0f1-c6fa-4642-2db0-69f090e8a392@oracle.com> (raw)
In-Reply-To: <20201216222549.GC3207@localhost.localdomain>

On 12/16/20 2:25 PM, Oscar Salvador wrote:
> On Wed, Dec 16, 2020 at 02:08:30PM -0800, Mike Kravetz wrote:
>>> + * vmemmap_rmap_walk - walk vmemmap page table
>>> +
>>> +static void vmemmap_pte_range(pmd_t *pmd, unsigned long addr,
>>> +			      unsigned long end, struct vmemmap_rmap_walk *walk)
>>> +{
>>> +	pte_t *pte;
>>> +
>>> +	pte = pte_offset_kernel(pmd, addr);
>>> +	do {
>>> +		BUG_ON(pte_none(*pte));
>>> +
>>> +		if (!walk->reuse)
>>> +			walk->reuse = pte_page(pte[VMEMMAP_TAIL_PAGE_REUSE]);
>>
>> It may be just me, but I don't like the pte[-1] here.  It certainly does work
>> as designed because we want to remap all pages in the range to the page before
>> the range (at offset -1).  But, we do not really validate this 'reuse' page.
>> There is the BUG_ON(pte_none(*pte)) as a sanity check, but we do nothing similar
>> for pte[-1].  Based on the usage for HugeTLB pages, we can be confident that
>> pte[-1] is actually a pte.  In discussions with Oscar, you mentioned another
>> possible use for these routines.
> 
> Without giving it much of a thought, I guess we could duplicate the
> BUG_ON for the pte outside the loop, and add a new one for pte[-1].
> Also, since walk->reuse seems to not change once it is set, we can take
> it outside the loop? e.g:
> 
> 	pte *pte;
> 
> 	pte = pte_offset_kernel(pmd, addr);
> 	BUG_ON(pte_none(*pte));
> 	BUG_ON(pte_none(pte[VMEMMAP_TAIL_PAGE_REUSE]));
> 	walk->reuse = pte_page(pte[VMEMMAP_TAIL_PAGE_REUSE]);
> 	do {
> 		....
> 	} while...
> 
> Or I am not sure whether we want to keep it inside the loop in case
> future cases change walk->reuse during the operation.
> But to be honest, I do not think it is realistic of all future possible
> uses of this, so I would rather keep it simple for now.

I was thinking about possibly passing the 'reuse' address as another parameter
to vmemmap_remap_reuse().  We could add this addr to the vmemmap_rmap_walk
struct and set walk->reuse when we get to the pte for that address.  Of
course this would imply that the addr would need to be part of the range.

Ideally, we would walk the page table to get to the reuse page.  My concern
was not explicitly about adding the BUG_ON.  In more general use, *pte could
be the first entry on a pte page.  And, then pte[-1] may not even be a pte.

Again, I don't think this matters for the current HugeTLB use case.  Just a
little concerned if code is put to use for other purposes.
-- 
Mike Kravetz

  reply	other threads:[~2020-12-16 22:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-13 15:45 [PATCH v9 00/11] Free some vmemmap pages of HugeTLB page Muchun Song
2020-12-13 15:45 ` [PATCH v9 01/11] mm/memory_hotplug: Factor out bootmem core functions to bootmem_info.c Muchun Song
2020-12-13 15:45 ` [PATCH v9 02/11] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-12-16  1:03   ` Mike Kravetz
2020-12-16  3:24     ` [External] " Muchun Song
2020-12-16  3:24       ` Muchun Song
2020-12-16  3:45     ` Mike Kravetz
2020-12-16  3:52       ` [External] " Muchun Song
2020-12-16  3:52         ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-16 13:06   ` Oscar Salvador
2020-12-16 13:15     ` [External] " Muchun Song
2020-12-16 13:15       ` Muchun Song
2020-12-16 22:08   ` Mike Kravetz
2020-12-16 22:25     ` Oscar Salvador
2020-12-16 22:49       ` Mike Kravetz [this message]
2020-12-17  6:54         ` [External] " Muchun Song
2020-12-17  6:54           ` Muchun Song
2020-12-17  9:05           ` Muchun Song
2020-12-17  9:05             ` Muchun Song
2020-12-17  4:06     ` Muchun Song
2020-12-17  4:06       ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 04/11] mm/hugetlb: Defer freeing of HugeTLB pages Muchun Song
2020-12-16 23:48   ` Mike Kravetz
2020-12-17  3:19     ` [External] " Muchun Song
2020-12-17  3:19       ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 05/11] mm/hugetlb: Allocate the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-17  1:17   ` Mike Kravetz
2020-12-17  3:22     ` [External] " Muchun Song
2020-12-17  3:22       ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 06/11] mm/hugetlb: Set the PageHWPoison to the raw error page Muchun Song
2020-12-16 13:28   ` Oscar Salvador
2020-12-16 13:51     ` [External] " Muchun Song
2020-12-16 13:51       ` Muchun Song
2020-12-16 13:30   ` Oscar Salvador
2020-12-13 15:45 ` [PATCH v9 07/11] mm/hugetlb: Flush work when dissolving hugetlb page Muchun Song
2020-12-13 15:45 ` [PATCH v9 08/11] mm/hugetlb: Add a kernel parameter hugetlb_free_vmemmap Muchun Song
2020-12-16 14:40   ` Oscar Salvador
2020-12-16 16:04     ` [External] " Muchun Song
2020-12-16 16:04       ` Muchun Song
2020-12-16 22:10       ` Oscar Salvador
2020-12-17  2:45         ` Muchun Song
2020-12-17  2:45           ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 09/11] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2020-12-16 13:43   ` Oscar Salvador
2020-12-16 13:56     ` [External] " Muchun Song
2020-12-16 13:56       ` Muchun Song
2020-12-16 22:12       ` Oscar Salvador
2020-12-17  8:34     ` Muchun Song
2020-12-17  8:34       ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 10/11] mm/hugetlb: Gather discrete indexes of tail page Muchun Song
2020-12-16 14:03   ` Oscar Salvador
2020-12-16 14:26     ` [External] " Muchun Song
2020-12-16 14:26       ` Muchun Song
2020-12-13 15:45 ` [PATCH v9 11/11] mm/hugetlb: Optimize the code with the help of the compiler Muchun Song
2020-12-17 10:31   ` Oscar Salvador
2020-12-17 10:42     ` [External] " Muchun Song
2020-12-17 10:42       ` Muchun Song

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=49f6a0f1-c6fa-4642-2db0-69f090e8a392@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=hpa@zytor.com \
    --cc=jroedel@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=oneukum@suse.com \
    --cc=osalvador@suse.de \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=songmuchun@bytedance.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /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.