From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
Yang Shi <yang.shi@linaro.org>, Laura Abbott <labbott@redhat.com>,
Vinayak Menon <vinmenon@codeaurora.org>,
zhong jiang <zhongjiang@huawei.com>
Subject: Re: [RFC PATCH 4/4] mm, page_ext: move page_ext_init() after page_alloc_init_late()
Date: Mon, 24 Jul 2017 15:06:13 +0200 [thread overview]
Message-ID: <20170724130613.GK25221@dhcp22.suse.cz> (raw)
In-Reply-To: <20170720134029.25268-5-vbabka@suse.cz>
On Thu 20-07-17 15:40:29, Vlastimil Babka wrote:
> Commit b8f1a75d61d8 ("mm: call page_ext_init() after all struct pages are
> initialized") has avoided a a NULL pointer dereference due to
> DEFERRED_STRUCT_PAGE_INIT clashing with page_ext, by calling page_ext_init()
> only after the deferred struct page init has finished. Later commit
> fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") avoided the
> underlying issue differently and moved the page_ext_init() call back to where
> it was before.
>
> However, there are two problems with the current code:
> - on very large machines, page_ext_init() may fail to allocate the page_ext
> structures, because deferred struct page init hasn't yet started, and the
> pre-inited part might be too small.
> This has been observed with a 3TB machine with page_owner=on. Although it
> was an older kernel where page_owner hasn't yet been converted to stack depot,
> thus page_ext was larger, the fundamental problem is still in mainline.
I was about to suggest using memblock/bootmem allocator but it seems
that page_ext_init is called passed mm_init. Is there any specific
reason why we cannot do the per-section initialization along with the
rest of the memory section init code which should have an early
allocator available?
> - page_owner's init_pages_in_zone() is called before deferred struct page init
> has started, so it will encounter unitialized struct pages. This currently
> happens to cause no harm, because the memmap array is are pre-zeroed on
> allocation and thus the "if (page_zone(page) != zone)" check is negative, but
> that pre-zeroing guarantee might change soon.
Yes this is annoying and the bug IMHO. We shouldn't consider spanned
pages but rather the maximum valid pfn for the zone. The rest simply
cannot by used by anybody so there shouldn't be any page_ext work due.
Or am I missing something?
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2017-07-24 13:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 13:40 [PATCH 0/4] page_ext/page_owner init fixes Vlastimil Babka
2017-07-20 13:40 ` [PATCH 1/4] mm, page_owner: make init_pages_in_zone() faster Vlastimil Babka
2017-07-24 12:38 ` Michal Hocko
2017-08-23 6:47 ` Vlastimil Babka
2017-08-24 7:01 ` Vlastimil Babka
2017-09-06 13:38 ` Michal Hocko
2017-08-31 7:55 ` Vlastimil Babka
2017-09-06 13:49 ` Michal Hocko
2017-09-06 13:55 ` Vlastimil Babka
2017-09-06 14:32 ` Michal Hocko
2017-07-20 13:40 ` [PATCH 2/4] mm, page_ext: periodically reschedule during page_ext_init() Vlastimil Babka
2017-07-24 12:45 ` Michal Hocko
2017-07-20 13:40 ` [PATCH 3/4] mm, page_owner: don't grab zone->lock for init_pages_in_zone() Vlastimil Babka
2017-07-24 12:50 ` Michal Hocko
2017-07-20 13:40 ` [RFC PATCH 4/4] mm, page_ext: move page_ext_init() after page_alloc_init_late() Vlastimil Babka
2017-07-24 13:06 ` Michal Hocko [this message]
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=20170724130613.GK25221@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=vbabka@suse.cz \
--cc=vinmenon@codeaurora.org \
--cc=yang.shi@linaro.org \
--cc=zhongjiang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).