Displaying 16 results from an estimated 16 matches for "pxm_to_node_map".
2019 Sep 23
2
[PATCH RFC v3 1/9] ACPI: NUMA: export pxm_to_node
...gt; 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index eadbf90e65d1..d5847fa7ac69 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
> return NUMA_NO_NODE;
> return pxm_to_node_map[pxm];
> }
> +EXPORT_SYMBOL(pxm_to_node);
FWIW, this is a fairly old patch I dragged along and I think I'll
convert this to EXPORT_SYMBOL_GPL now that I know better :)
>
> int node_to_pxm(int node)
> {
>
--
Thanks,
David / dhildenb
2019 Sep 23
2
[PATCH RFC v3 1/9] ACPI: NUMA: export pxm_to_node
...gt; 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> index eadbf90e65d1..d5847fa7ac69 100644
> --- a/drivers/acpi/numa.c
> +++ b/drivers/acpi/numa.c
> @@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
> return NUMA_NO_NODE;
> return pxm_to_node_map[pxm];
> }
> +EXPORT_SYMBOL(pxm_to_node);
FWIW, this is a fairly old patch I dragged along and I think I'll
convert this to EXPORT_SYMBOL_GPL now that I know better :)
>
> int node_to_pxm(int node)
> {
>
--
Thanks,
David / dhildenb
2019 Sep 19
0
[PATCH RFC v3 1/9] ACPI: NUMA: export pxm_to_node
...dhat.com>
---
drivers/acpi/numa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index eadbf90e65d1..d5847fa7ac69 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
return NUMA_NO_NODE;
return pxm_to_node_map[pxm];
}
+EXPORT_SYMBOL(pxm_to_node);
int node_to_pxm(int node)
{
--
2.21.0
2019 Sep 23
0
[PATCH RFC v3 1/9] ACPI: NUMA: export pxm_to_node
...>
> > diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
> > index eadbf90e65d1..d5847fa7ac69 100644
> > --- a/drivers/acpi/numa.c
> > +++ b/drivers/acpi/numa.c
> > @@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
> > return NUMA_NO_NODE;
> > return pxm_to_node_map[pxm];
> > }
> > +EXPORT_SYMBOL(pxm_to_node);
>
> FWIW, this is a fairly old patch I dragged along and I think I'll
> convert this to EXPORT_SYMBOL_GPL now that I know better :)
All other exports in this file are EXPORT_SYMBOL. Why is this one
considered special to restri...
2019 Dec 13
0
[PATCH RFC v4 01/13] ACPI: NUMA: export pxm_to_node
...t; diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
>> index eadbf90e65d1..d5847fa7ac69 100644
>> --- a/drivers/acpi/numa/srat.c
>> +++ b/drivers/acpi/numa/srat.c
>> @@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
>> return NUMA_NO_NODE;
>> return pxm_to_node_map[pxm];
>> }
>> +EXPORT_SYMBOL(pxm_to_node);
>>
>> int node_to_pxm(int node)
>> {
>>
>
> This is fine by me FWIW.
Can I count that as an Acked-by and carry it along? Thanks!
--
Thanks,
David / dhildenb
2020 Mar 02
0
[PATCH v1 01/11] ACPI: NUMA: export pxm_to_node
.../acpi/numa/srat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 47b4969d9b93..5be5a977da1b 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
return NUMA_NO_NODE;
return pxm_to_node_map[pxm];
}
+EXPORT_SYMBOL(pxm_to_node);
int node_to_pxm(int node)
{
--
2.24.1
2020 Mar 02
1
[PATCH v1 01/11] ACPI: NUMA: export pxm_to_node
...1 insertion(+)
>
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 47b4969d9b93..5be5a977da1b 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -35,6 +35,7 @@ int pxm_to_node(int pxm)
> return NUMA_NO_NODE;
> return pxm_to_node_map[pxm];
> }
> +EXPORT_SYMBOL(pxm_to_node);
>
> int node_to_pxm(int node)
> {
> --
> 2.24.1
>
--
Michal Hocko
SUSE Labs
2019 Dec 12
19
[PATCH RFC v4 00/13] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4
The basic idea of virtio-mem is to provide a flexible,
cross-architecture memory hot(un)plug solution that avoids many limitations
imposed by existing technologies, architectures, and interfaces. More
details can be found below and in linked material.
This
2019 Dec 12
19
[PATCH RFC v4 00/13] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-rfc-v4
The basic idea of virtio-mem is to provide a flexible,
cross-architecture memory hot(un)plug solution that avoids many limitations
imposed by existing technologies, architectures, and interfaces. More
details can be found below and in linked material.
This
2019 Sep 19
14
[PATCH RFC v3 0/9] virtio-mem: paravirtualized memory
Long time no RFC! I finally had time to get the next version of the Linux
driver side of virtio-mem into shape, incorporating ideas and feedback from
previous discussions.
This RFC is based on the series currently on the mm list:
- [PATCH 0/3] Remove __online_page_set_limits()
- [PATCH v1 0/3] mm/memory_hotplug: Export generic_online_page()
- [PATCH v4 0/8] mm/memory_hotplug: Shrink zones before
2020 Mar 02
20
[PATCH v1 00/11] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v1
The basic idea of virtio-mem is to provide a flexible,
cross-architecture memory hot(un)plug solution that avoids many limitations
imposed by existing technologies, architectures, and interfaces. More
details can be found below and in linked material.
It's
2020 Mar 02
20
[PATCH v1 00/11] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v1
The basic idea of virtio-mem is to provide a flexible,
cross-architecture memory hot(un)plug solution that avoids many limitations
imposed by existing technologies, architectures, and interfaces. More
details can be found below and in linked material.
It's
2020 May 07
17
[PATCH v4 00/15] virtio-mem: paravirtualized memory
This series is based on v5.7-rc4. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v4
This is basically a resend of v3 [1], now based on v5.7-rc4 and restested.
One patch was reshuffled and two ACKs I missed to add were added. The
rebase did not require any modifications to patches.
Details about virtio-mem can be found in the cover letter of v2 [2]. A
2020 Mar 11
12
[PATCH v2 00/10] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v2
I now have acks for all !virtio-mem changes. I'll be happy to get review
feedback, testing reports, etc. for the virtio-mem changes. If there are
no further comments, I guess this is good to go as a v1 soon.
The basic idea of virtio-mem is to provide a
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v3
Patch #1 - #10 where contained in v2 and only contain minor modifications
(mostly smaller fixes). The remaining patches are new and contain smaller
optimizations.
Details about virtio-mem can be found in the cover letter of v2 [1]. A
basic QEMU implementation was
2020 May 07
20
[PATCH v3 00/15] virtio-mem: paravirtualized memory
This series is based on latest linux-next. The patches are located at:
https://github.com/davidhildenbrand/linux.git virtio-mem-v3
Patch #1 - #10 where contained in v2 and only contain minor modifications
(mostly smaller fixes). The remaining patches are new and contain smaller
optimizations.
Details about virtio-mem can be found in the cover letter of v2 [1]. A
basic QEMU implementation was