All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Oscar Salvador <osalvador@suse.de>,
	Muchun Song <songmuchun@bytedance.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	viro@zeniv.linux.org.uk,
	Andrew Morton <akpm@linux-foundation.org>,
	paulmck@kernel.org, mchehab+huawei@kernel.org,
	pawan.kumar.gupta@linux.intel.com,
	Randy Dunlap <rdunlap@infradead.org>,
	oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de,
	Mina Almasry <almasrymina@google.com>,
	David Rientjes <rientjes@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@suse.com>,
	"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
	David Hildenbrand <david@redhat.com>,
	naoya.horiguchi@nec.com,
	Xiongchun duan <duanxiongchun@bytedance.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v10 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page
Date: Mon, 21 Dec 2020 17:03:54 -0800	[thread overview]
Message-ID: <238fcaca-b1f6-7bed-9307-72377eefb15f@oracle.com> (raw)
In-Reply-To: <20201221180019.GA2884@localhost.localdomain>

On 12/21/20 10:00 AM, Oscar Salvador wrote:
> On Mon, Dec 21, 2020 at 11:52:30PM +0800, Muchun Song wrote:
>> On Mon, Dec 21, 2020 at 9:44 PM Oscar Salvador <osalvador@suse.de> wrote:
>>>
>>> On Mon, Dec 21, 2020 at 07:25:15PM +0800, Muchun Song wrote:
>>>
>>>> Should we add a BUG_ON in vmemmap_remap_free() for now?
>>>>
>>>>         BUG_ON(reuse != start + PAGE_SIZE);
>>>
>>> I do not think we have to, plus we would be BUG_ing for some specific use
>>> case in "generic" function.
>>
>> The vmemmap_remap_range() walks page table range [start, end),
>> if reuse is equal to (start + PAGE_SIZE), the range can adjust to
>> [start - PAGE_SIZE, end). But if not, we need some work to
>> implement the "generic" function.
>>
>>   - adjust range to [min(start, reuse), end) and call
>>     vmemmap_remap_rangeand which skip the hole
>>     which is [reuse + PAGE_SIZE, start) or [end, reuse).
>>   - call vmemmap_remap_range(reuse, reuse + PAGE_SIZE)
>>     to get the reuse page.Then, call vmemmap_remap_range(start, end)
>>     again to remap.
>>
>> Which one do you prefer?
> 
> I would not overcomplicate things at this stage.
> Just follow my sugestion and add a BUG_ON as you said, that might be the
> easier way now.
> We can overthink this in the future when some other usecases come
> around, right?

I too like the suggestion of specifying the reuse address.  It is better
than than relying on 'start + PAGE_SIZE' or even 'start - PAGE_SIZE' as
in the previous version.

However, if we do allow this then we can not allow just any reuse address
without complicating the code.  Why?  Because the code would also need to
do a page table walk to validate reuse addr.  In the current code, that is
handled as long as reuse address is part of the range we are walking.

I see two assumptions in the current code:
1) reuse address is part of the range
2) remap_pte is found 'first' in table walk before we start remapping.

In the current use case, the 'reuse addr' is always going to be the start
of the page table range we walk.  Correct?  If so, perhaps it would just
be simpler for now to have range be
[reuse addr, last page mapped to reuse addr].  IOW, always have the range
start with reuse addr and all subsequent pages in the range are mapped to
reuse addr.  I know it is not very generic or flexible.  But, it might be
easier to understand than the adjustments (+- PAGE_SIZE) currently being
made in the code.

Just a thought.
-- 
Mike Kravetz

  reply	other threads:[~2020-12-22  1:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 12:12 [PATCH v10 00/11] Free some vmemmap pages of HugeTLB page Muchun Song
2020-12-17 12:12 ` [PATCH v10 01/11] mm/memory_hotplug: Factor out bootmem core functions to bootmem_info.c Muchun Song
2020-12-17 12:12 ` [PATCH v10 02/11] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-12-18 15:41   ` Oscar Salvador
2020-12-21 23:56   ` Mike Kravetz
2020-12-17 12:12 ` [PATCH v10 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-21  9:11   ` Oscar Salvador
2020-12-21 11:25     ` [External] " Muchun Song
2020-12-21 11:25       ` Muchun Song
2020-12-21 13:43       ` Oscar Salvador
2020-12-21 15:52         ` Muchun Song
2020-12-21 15:52           ` Muchun Song
2020-12-21 18:00           ` Oscar Salvador
2020-12-22  1:03             ` Mike Kravetz [this message]
2020-12-22  2:49             ` Muchun Song
2020-12-22  2:49               ` Muchun Song
2020-12-17 12:12 ` [PATCH v10 04/11] mm/hugetlb: Defer freeing of HugeTLB pages Muchun Song
2020-12-21 10:27   ` Oscar Salvador
2020-12-21 11:07     ` [External] " Muchun Song
2020-12-21 11:07       ` Muchun Song
2020-12-21 14:14       ` Oscar Salvador
2020-12-21 15:18         ` Muchun Song
2020-12-21 15:18           ` Muchun Song
2020-12-17 12:12 ` [PATCH v10 05/11] mm/hugetlb: Allocate the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-17 12:12 ` [PATCH v10 06/11] mm/hugetlb: Set the PageHWPoison to the raw error page Muchun Song
2020-12-17 12:12 ` [PATCH v10 07/11] mm/hugetlb: Flush work when dissolving hugetlb page Muchun Song
2020-12-21 10:40   ` Oscar Salvador
2020-12-21 11:07     ` [External] " Muchun Song
2020-12-21 11:07       ` Muchun Song
2020-12-17 12:13 ` [PATCH v10 08/11] mm/hugetlb: Add a kernel parameter hugetlb_free_vmemmap Muchun Song
2020-12-17 12:13 ` [PATCH v10 09/11] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2020-12-21  8:16   ` Oscar Salvador
2020-12-21  9:33     ` [External] " Muchun Song
2020-12-21  9:33       ` Muchun Song
2020-12-17 12:13 ` [PATCH v10 10/11] mm/hugetlb: Gather discrete indexes of tail page Muchun Song
2020-12-18  9:06   ` Oscar Salvador
2020-12-18  9:41     ` [External] " Muchun Song
2020-12-18  9:41       ` Muchun Song
2020-12-17 12:13 ` [PATCH v10 11/11] mm/hugetlb: Optimize the code with the help of the compiler Muchun Song
2020-12-17 12:17 ` [PATCH v10 00/11] Free some vmemmap pages of HugeTLB page David Hildenbrand
2020-12-17 14:59 ` Oscar Salvador
2020-12-17 15:52   ` [External] " Muchun Song
2020-12-17 15:52     ` 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=238fcaca-b1f6-7bed-9307-72377eefb15f@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=naoya.horiguchi@nec.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.