From: David Hildenbrand <david@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>,
Dan Williams <dan.j.williams@intel.com>
Cc: akpm@linux-foundation.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
peterz@infradead.org, ard.biesheuvel@linaro.org,
linux-mm@kvack.org, linux-nvdimm@lists.01.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 11/23] device-dax: Kill dax_kmem_res
Date: Tue, 8 Sep 2020 20:03:31 +0200 [thread overview]
Message-ID: <25856e56-6afd-6efe-a396-f5a50b77f1f6@redhat.com> (raw)
In-Reply-To: <17686fcc-202e-0982-d0de-54d5349cfb5d@oracle.com>
>>> + release_mem_region(range.start, range_len(&range));
>>
>> remove_memory() does a release_mem_region_adjustable(). Don't you
>> actually want to release the *unaligned* region you requested?
>>
> Isn't it what we're doing here?
> (The release_mem_region_adjustable() is using the same
> dax_kmem-aligned range and there's no split/adjust)
Oh, I think I was messing up things (there is just too much going on in
this patch).
Right, request_mem_region() and add_memory_driver_managed() are - and
were - called with the exact same range. That would have been clearer if
the patch would simply use range.start and range_len(&range) for both
calls (similar in the original code).
So, also the release calls have to use the same range. Agreed.
>
> Meaning right now (+ parent marked as !BUSY), and if I am understanding
> this correctly:
>
> request_mem_region(range.start, range_len)
> __request_region(iomem_res, range.start, range_len) -> alloc @parent
> add_memory_driver_managed(parent.start, resource_size(parent))
> __request_region(parent.start, resource_size(parent)) -> alloc @child
>
> [...]
>
> remove_memory(range.start, range_len)
> request_mem_region_adjustable(range.start, range_len)
> __release_region(range.start, range_len) -> remove @child
>
> release_mem_region(range.start, range_len)
> __release_region(range.start, range_len) -> doesn't remove @parent because !BUSY?
>
> The add/removal of this relies on !BUSY. But now I am wondering if the parent remaining
> unreleased is deliberate even on CONFIG_MEMORY_HOTREMOVE=y.
Interesting, I can only tell that virtio-mem expects that
remove_memory() won't remove the parent resource (which is !BUSY). So it
relies on the existing functionality.
I do wonder how walk_system_ram_range() behaves if both the parent and
the child are BUSY. Looking at it, I think it will detect the parent and
skip to the next range (without visiting the child) - which is not what
we want.
We could set the parent to BUSY just before doing the
release_mem_region() call, but that feels like a hack.
Maybe it's just easier to keep dax_kmem_res around ...
--
Thanks,
David / dhildenb
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
next prev parent reply other threads:[~2020-09-08 18:03 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-03 5:02 [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges Dan Williams
2020-08-03 5:02 ` [PATCH v4 01/23] x86/numa: Cleanup configuration dependent command-line options Dan Williams
2020-08-03 5:02 ` [PATCH v4 02/23] x86/numa: Add 'nohmat' option Dan Williams
2020-08-03 5:02 ` [PATCH v4 03/23] efi/fake_mem: Arrange for a resource entry per efi_fake_mem instance Dan Williams
2020-08-03 5:02 ` [PATCH v4 04/23] ACPI: HMAT: Refactor hmat_register_target_device to hmem_register_device Dan Williams
2020-08-03 5:02 ` [PATCH v4 05/23] resource: Report parent to walk_iomem_res_desc() callback Dan Williams
2020-08-03 5:02 ` [PATCH v4 06/23] mm/memory_hotplug: Introduce default phys_to_target_node() implementation Dan Williams
2020-08-03 5:03 ` [PATCH v4 07/23] ACPI: HMAT: Attach a device for each soft-reserved range Dan Williams
2020-08-03 5:03 ` [PATCH v4 08/23] device-dax: Drop the dax_region.pfn_flags attribute Dan Williams
2020-08-03 5:03 ` [PATCH v4 09/23] device-dax: Move instance creation parameters to 'struct dev_dax_data' Dan Williams
2020-08-03 5:03 ` [PATCH v4 10/23] device-dax: Make pgmap optional for instance creation Dan Williams
2020-08-03 5:03 ` [PATCH v4 11/23] device-dax: Kill dax_kmem_res Dan Williams
2020-08-21 10:06 ` David Hildenbrand
2020-09-08 15:33 ` Joao Martins
2020-09-08 18:03 ` David Hildenbrand [this message]
2020-09-23 8:04 ` David Hildenbrand
2020-09-23 21:41 ` Dan Williams
2020-09-24 7:25 ` David Hildenbrand
2020-09-24 13:54 ` Dan Williams
2020-09-24 18:12 ` David Hildenbrand
2020-09-24 21:26 ` Dan Williams
2020-09-24 21:41 ` David Hildenbrand
2020-09-24 21:50 ` Dan Williams
2020-09-25 8:54 ` David Hildenbrand
2020-08-03 5:03 ` [PATCH v4 12/23] device-dax: Add an allocation interface for device-dax instances Dan Williams
2020-08-03 5:03 ` [PATCH v4 13/23] device-dax: Introduce 'seed' devices Dan Williams
2020-08-03 5:03 ` [PATCH v4 14/23] drivers/base: Make device_find_child_by_name() compatible with sysfs inputs Dan Williams
2020-08-03 5:03 ` [PATCH v4 15/23] device-dax: Add resize support Dan Williams
2020-08-21 22:56 ` Andrew Morton
2020-08-03 5:03 ` [PATCH v4 16/23] mm/memremap_pages: Convert to 'struct range' Dan Williams
2020-08-03 5:03 ` [PATCH v4 17/23] mm/memremap_pages: Support multiple ranges per invocation Dan Williams
2020-08-03 5:04 ` [PATCH v4 18/23] device-dax: Add dis-contiguous resource support Dan Williams
2020-08-03 5:04 ` [PATCH v4 19/23] device-dax: Introduce 'mapping' devices Dan Williams
2020-08-03 5:04 ` [PATCH v4 20/23] device-dax: Make align a per-device property Dan Williams
2020-08-03 5:04 ` [PATCH v4 21/23] device-dax: Add an 'align' attribute Dan Williams
2020-08-03 5:04 ` [PATCH v4 22/23] dax/hmem: Introduce dax_hmem.region_idle parameter Dan Williams
2020-08-03 5:04 ` [PATCH v4 23/23] device-dax: Add a range mapping allocation attribute Dan Williams
2020-08-03 7:47 ` [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges David Hildenbrand
2020-08-20 1:53 ` Dan Williams
2020-08-21 10:15 ` David Hildenbrand
2020-08-21 18:27 ` Dan Williams
2020-08-21 18:30 ` David Hildenbrand
2020-08-21 21:17 ` Dan Williams
2020-08-21 21:33 ` David Hildenbrand
2020-08-21 21:42 ` David Hildenbrand
2020-08-21 21:43 ` David Hildenbrand
2020-08-21 21:46 ` David Hildenbrand
2020-08-21 23:21 ` Andrew Morton
2020-08-22 2:32 ` Leizhen (ThunderTown)
2020-09-08 10:45 ` David Hildenbrand
2020-09-23 0:43 ` 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=25856e56-6afd-6efe-a396-f5a50b77f1f6@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=joao.m.martins@oracle.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=pasha.tatashin@soleen.com \
--cc=peterz@infradead.org \
/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).