From: David Hildenbrand <david@redhat.com>
To: linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Scargall, Steve" <steve.scargall@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>
Subject: Re: [PATCH] mm: Fix false softlockup during pfn range removal
Date: Mon, 22 Jun 2020 18:29:12 +0200 [thread overview]
Message-ID: <c0f68df5-e39f-2252-43b9-1e54ba707e9f@redhat.com> (raw)
In-Reply-To: <20200622162527.bo765xhid563u6vp@intel.com>
>>> Alternately, init_page_poison could do this cond_resched(), but it seems
>>> to me that the caller of init_page_poison() is what actually knows
>>> whether or not it should relax its own priority.
>>>
>>> Based on Dan's notes, I think this is perfectly safe:
>>> commit f931ab479dd2 ("mm: fix devm_memremap_pages crash, use mem_hotplug_{begin, done}")
>>
>> We shouldn't be holding any spin locks, so it's safe. (we could think
>> about doing this outside of the memory hotplug lock in the case of
>> devmem, however, it's only a debugging feature so we most probably don't
>> care).
>>
>>>
>>> Aside from fixing the lockup, it is also a friendlier thing to do on
>>> lower core systems that might wipe out large chunks of hotplug memory
>>> (probably not a very common case).
>>
>> It really only is an issue for devmem. Ordinary hotplugged system memory
>> is not affected (onlined/offlined in memory block granularity).
>
> Could you explain this a bit? I was fixing the issue found on PMEM systems, but
> it seems like regularly memory hotplug was potentially a victim. I think one of
> the reasons PMEM might be more likely is the time it takes to work with any data
> structures store in the PMEM itself is slower (just a guess).
For system RAM, we have have (except one ppc exception):
memory_block_action()->offline_pages()->remove_pfn_range_from_zone()
Memory blocks span 1..X sections, usually only one. On x86-64, a memory
block is therefore 128MB..2G. Not a sufficiently large memmap to
actually trigger this - in contrast to ZONE_DEVICE regions.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-06-22 16:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-19 23:12 [PATCH] mm: Fix false softlockup during pfn range removal Ben Widawsky
2020-06-22 7:16 ` David Hildenbrand
2020-06-22 16:25 ` Ben Widawsky
2020-06-22 16:29 ` David Hildenbrand [this message]
2020-06-23 7:18 ` David Hildenbrand
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=c0f68df5-e39f-2252-43b9-1e54ba707e9f@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=linux-mm@kvack.org \
--cc=steve.scargall@intel.com \
--cc=vishal.l.verma@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 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).