LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Daniel Jordan <daniel.m.jordan@oracle.com>
To: Shile Zhang <shile.zhang@linux.alibaba.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] mm: fix tick timer stall during deferred page init
Date: Thu, 19 Mar 2020 15:05:12 -0400 [thread overview]
Message-ID: <20200319190512.cwnvgvv3upzcchkm@ca-dmjordan1.us.oracle.com> (raw)
In-Reply-To: <20200311123848.118638-1-shile.zhang@linux.alibaba.com>
On Wed, Mar 11, 2020 at 08:38:48PM +0800, Shile Zhang wrote:
Sorry, I'm late to this.
I don't have a better solution, but I did try to find a way to stop holding the
resize lock during (most of) page init, which would make this fix unnecessary
and the deferred_init_memmap context less strange. Here are some ideas that
didn't work out in case someone sees a different way forward.
One thought is to unify the common parts of deferred_init_memmap and
deferred_grow_zone and have callers grab chunks of pages to initialize and note
the next available page to initialize for the next caller. Interrupt handlers
participate in page init while it's happening rather than having to wait until
it's finished. But what if a partially completed chunk is interrupted midway
through and the interrupt handler needs to allocate those in-progress pages?
May be possible to guarantee some memory is available if some minimum number of
chunks have been completed already, but it's hard to say what that number is if
the amount of memory handlers might allocate is unbounded.
Given that large allocations from interrupt handlers is a theoretical issue,
another thought is to reserve one section for deferred_grow_zone, should it be
called during page init, and if not then the pgdatinit thread could initialize
it with the resize lock held after the rest of page init is finished.
Meanwhile regular page init need not hold the resize lock. If interrupt
handlers try to allocate more than a section during this time, trigger a
warning so we know the issue isn't theoretical. The downside is that it's
possible this may not fix it for good.
> @@ -1811,9 +1816,23 @@ static int __init deferred_init_memmap(v
> * that we can avoid introducing any issues with the buddy
> * allocator.
> */
> - while (spfn < epfn)
> + while (spfn < epfn) {
> nr_pages += deferred_init_maxorder(&i, zone, &spfn, &epfn);
> + /*
> + * Release the interrupts for every TICK_PAGE_COUNT pages
> + * (128MB) to give tick timer the chance to update the
> + * system jiffies.
> + */
> + if ((nr_pages - prev_nr_pages) > TICK_PAGE_COUNT) {
> + prev_nr_pages = nr_pages;
> + pgdat->first_deferred_pfn = spfn;
> + pgdat_resize_unlock(pgdat, &flags);
> + goto again;
> + }
> + }
> +
Nits only:
- s/Release the interrupts/Enable interrupts/
- take out 128MB, that assumes PAGE_SIZE is 4k
I considered saving i, spfn, and epfn in pgdat to avoid having to rerun
deferred_init_mem_pfn_range_in_zone every retry, but it'd enlarge pgdat for
short-lived data and the function probably isn't expensive.
Regardless,
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
next prev parent reply other threads:[~2020-03-19 19:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 12:38 Shile Zhang
2020-03-11 17:45 ` Pavel Tatashin
2020-03-11 20:16 ` Kirill Tkhai
2020-03-11 20:25 ` Pavel Tatashin
2020-03-19 19:05 ` Daniel Jordan [this message]
2020-03-26 18:58 ` Daniel Jordan
2020-03-26 19:36 ` Pavel Tatashin
2020-03-27 4:39 ` Shile Zhang
2020-03-28 0:17 ` Daniel Jordan
2020-04-01 14:26 ` David Hildenbrand
2020-04-01 15:42 ` Michal Hocko
2020-04-01 15:50 ` David Hildenbrand
2020-04-01 16:00 ` Michal Hocko
2020-04-01 16:09 ` Daniel Jordan
2020-04-01 16:12 ` Michal Hocko
2020-04-01 16:15 ` David Hildenbrand
2020-04-01 16:18 ` Daniel Jordan
2020-04-01 16:26 ` Michal Hocko
2020-04-01 16:41 ` Pavel Tatashin
2020-04-01 16:46 ` Michal Hocko
2020-04-01 16:51 ` Pavel Tatashin
2020-04-01 17:13 ` Daniel Jordan
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=20200319190512.cwnvgvv3upzcchkm@ca-dmjordan1.us.oracle.com \
--to=daniel.m.jordan@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ktkhai@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=shile.zhang@linux.alibaba.com \
--subject='Re: [PATCH v3] mm: fix tick timer stall during deferred page init' \
/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
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).