From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v1 01/11] ACPI: NUMA: export pxm_to_node
Date: Mon, 2 Mar 2020 15:09:10 +0100 [thread overview]
Message-ID: <baff6701-fc75-d205-2e78-904166f63030@redhat.com> (raw)
In-Reply-To: <20200302140309.GM4380@dhcp22.suse.cz>
On 02.03.20 15:03, Michal Hocko wrote:
> On Mon 02-03-20 14:49:31, David Hildenbrand wrote:
>> Will be needed by virtio-mem to identify the node from a pxm.
>
> No objection to export the symbol. But it is almost always better to add
> the export in the patch that actually uses it. The intention is much
> more clear that way.
Yeah, but I guess this way people might take more likely a look as if
this would be squashed into a
5 files changed, 1786 insertions(+)
patch. At least that's what my experience tells me :)
If there are hard feelings, I can squash (but I am afraid it will be
even harder to get ACKs/RBs for core-mm changes that way ...)
Thanks for having a look!
--
Thanks,
David / dhildenb
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org
Subject: [virtio-dev] Re: [PATCH v1 01/11] ACPI: NUMA: export pxm_to_node
Date: Mon, 2 Mar 2020 15:09:10 +0100 [thread overview]
Message-ID: <baff6701-fc75-d205-2e78-904166f63030@redhat.com> (raw)
In-Reply-To: <20200302140309.GM4380@dhcp22.suse.cz>
On 02.03.20 15:03, Michal Hocko wrote:
> On Mon 02-03-20 14:49:31, David Hildenbrand wrote:
>> Will be needed by virtio-mem to identify the node from a pxm.
>
> No objection to export the symbol. But it is almost always better to add
> the export in the patch that actually uses it. The intention is much
> more clear that way.
Yeah, but I guess this way people might take more likely a look as if
this would be squashed into a
5 files changed, 1786 insertions(+)
patch. At least that's what my experience tells me :)
If there are hard feelings, I can squash (but I am afraid it will be
even harder to get ACKs/RBs for core-mm changes that way ...)
Thanks for having a look!
--
Thanks,
David / dhildenb
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-03-02 14:09 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-02 13:49 [PATCH v1 00/11] virtio-mem: paravirtualized memory David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 01/11] ACPI: NUMA: export pxm_to_node David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 14:03 ` Michal Hocko
2020-03-02 14:09 ` David Hildenbrand [this message]
2020-03-02 14:09 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 02/11] virtio-mem: Paravirtualized memory hotplug David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-03 2:24 ` kbuild test robot
2020-03-03 2:24 ` kbuild test robot
2020-03-03 2:24 ` kbuild test robot
2020-03-03 8:06 ` David Hildenbrand
2020-03-03 8:06 ` [virtio-dev] " David Hildenbrand
2020-03-03 8:06 ` David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 03/11] virtio-mem: Paravirtualized memory hotunplug part 1 David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 04/11] mm: Export alloc_contig_range() / free_contig_range() David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 14:05 ` Michal Hocko
2020-03-02 14:17 ` David Hildenbrand
2020-03-02 14:17 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 05/11] virtio-mem: Paravirtualized memory hotunplug part 2 David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 06/11] mm: Allow to offline unmovable PageOffline() pages via MEM_GOING_OFFLINE David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 17:40 ` Alexander Duyck
2020-03-02 17:40 ` [virtio-dev] " Alexander Duyck
2020-03-02 17:40 ` Alexander Duyck
2020-03-02 17:40 ` Alexander Duyck
2020-03-02 18:41 ` David Hildenbrand
2020-03-02 18:41 ` [virtio-dev] " David Hildenbrand
2020-03-10 11:47 ` Michal Hocko
2020-03-10 11:47 ` Michal Hocko
2020-03-10 11:48 ` David Hildenbrand
2020-03-10 11:48 ` [virtio-dev] " David Hildenbrand
2020-03-10 11:48 ` David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 07/11] virtio-mem: Allow to offline partially unplugged memory blocks David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-10 11:43 ` Michal Hocko
2020-03-10 11:46 ` David Hildenbrand
2020-03-10 11:46 ` [virtio-dev] " David Hildenbrand
2020-03-10 11:59 ` Michal Hocko
2020-03-10 12:09 ` David Hildenbrand
2020-03-10 12:09 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 08/11] mm/memory_hotplug: Introduce offline_and_remove_memory() David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 14:27 ` Michal Hocko
2020-03-02 13:49 ` [PATCH v1 09/11] virtio-mem: Offline and remove completely unplugged memory blocks David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 10/11] virtio-mem: Better retry handling David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 13:49 ` [PATCH v1 11/11] MAINTAINERS: Add myself as virtio-mem maintainer David Hildenbrand
2020-03-02 13:49 ` [virtio-dev] " David Hildenbrand
2020-03-02 18:15 ` [PATCH v1 00/11] virtio-mem: paravirtualized memory David Hildenbrand
2020-03-02 18:15 ` [virtio-dev] " David Hildenbrand
2020-03-02 18:15 ` David Hildenbrand
2020-03-02 18:29 ` Michal Hocko
2020-03-02 18:29 ` Michal Hocko
2020-03-02 18:41 ` David Hildenbrand
2020-03-02 18:41 ` [virtio-dev] " David Hildenbrand
2020-03-02 18:41 ` 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=baff6701-fc75-d205-2e78-904166f63030@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mst@redhat.com \
--cc=rafael@kernel.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.