From: zhong jiang <zhongjiang@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mm: respect pre-allocated storage mapping for memmap
Date: Wed, 18 Jan 2017 18:09:51 +0800 [thread overview]
Message-ID: <587F3EEF.1030100@huawei.com> (raw)
In-Reply-To: <CAPcyv4j75n6LzrW=j+ehtGBksj_F32RAE4uLQna3wp4y-MOSKw@mail.gmail.com>
On 2017/1/18 1:15, Dan Williams wrote:
> On Tue, Jan 17, 2017 at 5:58 AM, zhong jiang <zhongjiang@huawei.com> wrote:
>> On 2017/1/17 18:25, Michal Hocko wrote:
>>> On Mon 16-01-17 21:38:05, zhongjiang wrote:
>>>> From: zhong jiang <zhongjiang@huawei.com>
>>>>
>>>> At present, we skip the reservation storage by the driver for
>>>> the zone_dvice. but the free pages set aside for the memmap is
>>>> ignored. And since the free pages is only used as the memmap,
>>>> so we can also skip the corresponding pages.
>>> I have really hard time to understand what this patch does and why it
>>> matters. Could you please rephrase the changelog to state, the problem,
>>> how it affects users and what is the fix please?
>>>
>> Hi, Michal
>>
>> The patch maybe incorrect if free pages for memmap mapping is accouted for zone_device.
>> I am just a little confusing about the implement. it maybe simple and stupid.
> The patch is incorrect, the struct page initialization starts
> immediately after altmap->reserve.
>
>> first pfn for dev_mappage come from vmem_altmap_offset, and free pages reserved for
>> memmap mapping need to be accounted. I do not know the meaning.
>>
>> Another issue is in sparse_remove_one_section. A section belongs to zone_device is not
>> always need to consider the map_offset. is it right ? From pfn_first to end , that section
>> should no need to consider the map_offet.
> No that's not right. devm_memremap_pages() will specify the full
> physical address range that was initially hotplugged. At removal time
> the first page of the memmap starts at pfn_to_page(phys_start_pfn +
> map_offset).
>
> However, I always need to remind myself of these rules every time I
> read the code, so the documentation needs improvement.
The rules ensure that (reserve + free) need to less than one section size.
if it is so, or we add WARNON to explicitly the limits.
Thanks
zhongjiang
> .
>
--
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>
next prev parent reply other threads:[~2017-01-18 10:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 13:38 zhongjiang
2017-01-16 14:43 ` Anshuman Khandual
2017-01-17 8:14 ` zhong jiang
2017-01-17 10:25 ` Michal Hocko
2017-01-17 13:58 ` zhong jiang
2017-01-17 17:15 ` Dan Williams
2017-01-18 10:09 ` zhong jiang [this message]
2017-01-18 13:27 ` zhong jiang
2017-01-18 15:39 ` Dan Williams
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=587F3EEF.1030100@huawei.com \
--to=zhongjiang@huawei.com \
--cc=dan.j.williams@intel.com \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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