Displaying 11 results from an estimated 11 matches for "mhp_flags".
Did you mean:
map_flags
2020 Sep 10
0
[PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...extern void __ref free_area_init_core_hotplug(int nid);
-extern int __add_memory(int nid, u64 start, u64 size);
-extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource);
+extern int __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
+extern int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
+extern int add_memory_resource(int nid, struct resource *resource,
+ mhp_t mhp_flags);
extern int add_memory_driver_managed(int nid, u64 start, u64 size,
- const char *resource_name);
+ const char *r...
2020 Sep 11
1
[PATCH v3 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...In file included from include/linux/slab.h:15:
In file included from include/linux/gfp.h:6:
In file included from include/linux/mmzone.h:853:
>> include/linux/memory_hotplug.h:354:55: error: unknown type name 'mhp_t'
extern int __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
^
include/linux/memory_hotplug.h:355:53: error: unknown type name 'mhp_t'
extern int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags);
^
include/linux/memory_hotplug.h:357:11: error: unknown type name 'mhp_t'
mhp_t mhp_flags);
^
include/linux/memor...
2020 Sep 10
9
[PATCH v3 0/7] mm/memory_hotplug: selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 09
2
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...ags", and how do we know what should be passed
>> to them?
>>
>> Why not make this an enumerated type so that we know it all works
>> properly, like the GPF_* flags are? Passing around a random unsigned
>> long feels very odd/broken...
>
> Agreed, an enum (mhp_flags) seems to give a better hint what can
> actually be passed. Thanks!
You probably know this but ...
Just using a C enum doesn't get you any type safety.
You can get some checking via sparse by using __bitwise, which is what
gfp_t does. You don't actually have to use an enum for that, i...
2020 Sep 09
2
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...ags", and how do we know what should be passed
>> to them?
>>
>> Why not make this an enumerated type so that we know it all works
>> properly, like the GPF_* flags are? Passing around a random unsigned
>> long feels very odd/broken...
>
> Agreed, an enum (mhp_flags) seems to give a better hint what can
> actually be passed. Thanks!
You probably know this but ...
Just using a C enum doesn't get you any type safety.
You can get some checking via sparse by using __bitwise, which is what
gfp_t does. You don't actually have to use an enum for that, i...
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 09
2
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that we know it all works
properly, like the GPF_* flags are? Passing around a random
2020 Sep 09
2
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that we know it all works
properly, like the GPF_* flags are? Passing around a random
2020 Sep 09
0
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...hat are these random "flags", and how do we know what should be passed
> to them?
>
> Why not make this an enumerated type so that we know it all works
> properly, like the GPF_* flags are? Passing around a random unsigned
> long feels very odd/broken...
Agreed, an enum (mhp_flags) seems to give a better hint what can
actually be passed. Thanks!
--
Thanks,
David / dhildenb
2020 Sep 09
0
[PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends
...ow what should be passed
>>> to them?
>>>
>>> Why not make this an enumerated type so that we know it all works
>>> properly, like the GPF_* flags are? Passing around a random unsigned
>>> long feels very odd/broken...
>>
>> Agreed, an enum (mhp_flags) seems to give a better hint what can
>> actually be passed. Thanks!
>
> You probably know this but ...
>
> Just using a C enum doesn't get you any type safety.
>
> You can get some checking via sparse by using __bitwise, which is what
> gfp_t does. You don't a...