From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Vlastimil Babka <vbabka@suse.cz>, Mel Gorman <mgorman@suse.de>,
"Jin, Zhi" <zhi.jin@intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH] mm/page_alloc: Skip non present sections on zone initialization
Date: Fri, 10 Jan 2020 14:15:26 +0100 [thread overview]
Message-ID: <73437651-822f-fcec-3b96-281fb1064cf8@redhat.com> (raw)
In-Reply-To: <20200108144044.GB30379@dhcp22.suse.cz>
On 08.01.20 15:40, Michal Hocko wrote:
> On Mon 30-12-19 12:38:28, Kirill A. Shutemov wrote:
>> memmap_init_zone() can be called on the ranges with holes during the
>> boot. It will skip any non-valid PFNs one-by-one. It works fine as long
>> as holes are not too big.
>>
>> But huge holes in the memory map causes a problem. It takes over 20
>> seconds to walk 32TiB hole. x86-64 with 5-level paging allows for much
>> larger holes in the memory map which would practically hang the system.
>>
>> Deferred struct page init doesn't help here. It only works on the
>> present ranges.
>>
>> Skipping non-present sections would fix the issue.
>
> Makes sense to me.
>
>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>
> That pfn inc back and forth is quite ugly TBH but whatever.
Indeed, can we please rewrite the loop to fix that?
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-01-10 13:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 9:38 [PATCH] mm/page_alloc: Skip non present sections on zone initialization Kirill A. Shutemov
2019-12-31 1:23 ` Baoquan He
2019-12-31 1:33 ` Baoquan He
2020-01-08 14:40 ` Michal Hocko
2020-01-10 13:15 ` David Hildenbrand [this message]
2020-01-10 13:45 ` Kirill A. Shutemov
2020-01-10 14:34 ` David Hildenbrand
2020-01-10 14:47 ` Kirill A. Shutemov
2020-01-10 14:48 ` David Hildenbrand
2020-01-10 14:54 ` Kirill A. Shutemov
2020-01-10 14:56 ` David Hildenbrand
2020-01-10 17:55 ` Kirill A. Shutemov
2020-01-10 18:05 ` David Hildenbrand
2020-01-10 18:22 ` Kirill A. Shutemov
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=73437651-822f-fcec-3b96-281fb1064cf8@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
--cc=zhi.jin@intel.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.