Re: use generic DMA mapping code in powerpc V4
On Fri, 2018-11-30 at 11:44 +, Rui Salvaterra wrote: > Thanks for the quick response! I applied it on top of your > powerpc-dma.4 branch and retested. > I'm not seeing nouveau complaining anymore (I'm not using X11 or any > DE, though). > In any case and FWIW, this series is > > Tested-by: Rui Salvaterra Talking of which ... Christoph, not sure if we can do something about this at the DMA API level or keep hacks but some adapters such as the nVidia GPUs have a HW hack we can use to work around their limitations in that case. They have a register that can program a fixed value for the top bits that they don't support. This works fine for any linear mapping with an offset, provided they can program the offset in that register and they have enough DMA range to cover all memory from that offset. I can probably get the info about this from them so we can exploit it in nouveau. Cheers, Ben. > Thanks, > Rui
Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types
On Fri, Nov 30, 2018 at 06:59:18PM +0100, David Hildenbrand wrote:
>This is the second approach, introducing more meaningful memory block
>types and not changing online behavior in the kernel. It is based on
>latest linux-next.
>
>As we found out during dicussion, user space should always handle onlining
>of memory, in any case. However in order to make smart decisions in user
>space about if and how to online memory, we have to export more information
>about memory blocks. This way, we can formulate rules in user space.
>
>One such information is the type of memory block we are talking about.
>This helps to answer some questions like:
>- Does this memory block belong to a DIMM?
>- Can this DIMM theoretically ever be unplugged again?
>- Was this memory added by a balloon driver that will rely on balloon
> inflation to remove chunks of that memory again? Which zone is advised?
>- Is this special standby memory on s390x that is usually not automatically
> onlined?
>
>And in short it helps to answer to some extend (excluding zone imbalances)
>- Should I online this memory block?
>- To which zone should I online this memory block?
>... of course special use cases will result in different anwers. But that's
>why user space has control of onlining memory.
>
>More details can be found in Patch 1 and Patch 3.
>Tested on x86 with hotplugged DIMMs. Cross-compiled for PPC and s390x.
>
>
>Example:
>$ udevadm info -q all -a /sys/devices/system/memory/memory0
> KERNEL=="memory0"
> SUBSYSTEM=="memory"
> DRIVER==""
> ATTR{online}=="1"
> ATTR{phys_device}=="0"
> ATTR{phys_index}==""
> ATTR{removable}=="0"
> ATTR{state}=="online"
> ATTR{type}=="boot"
> ATTR{valid_zones}=="none"
>$ udevadm info -q all -a /sys/devices/system/memory/memory90
> KERNEL=="memory90"
> SUBSYSTEM=="memory"
> DRIVER==""
> ATTR{online}=="1"
> ATTR{phys_device}=="0"
> ATTR{phys_index}=="005a"
> ATTR{removable}=="1"
> ATTR{state}=="online"
> ATTR{type}=="dimm"
> ATTR{valid_zones}=="Normal"
>
>
>RFC -> RFCv2:
>- Now also taking care of PPC (somehow missed it :/ )
>- Split the series up to some degree (some ideas on how to split up patch 3
> would be very welcome)
>- Introduce more memory block types. Turns out abstracting too much was
> rather confusing and not helpful. Properly document them.
>
>Notes:
>- I wanted to convert the enum of types into a named enum but this
> provoked all kinds of different errors. For now, I am doing it just like
> the other types (e.g. online_type) we are using in that context.
>- The "removable" property should never have been named like that. It
> should have been "offlinable". Can we still rename that? E.g. boot memory
> is sometimes marked as removable ...
>
This make sense to me. Remove usually describe physical hotplug phase,
if I am correct.
--
Wei Yang
Help you, Help me
[PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types
This is the second approach, introducing more meaningful memory block
types and not changing online behavior in the kernel. It is based on
latest linux-next.
As we found out during dicussion, user space should always handle onlining
of memory, in any case. However in order to make smart decisions in user
space about if and how to online memory, we have to export more information
about memory blocks. This way, we can formulate rules in user space.
One such information is the type of memory block we are talking about.
This helps to answer some questions like:
- Does this memory block belong to a DIMM?
- Can this DIMM theoretically ever be unplugged again?
- Was this memory added by a balloon driver that will rely on balloon
inflation to remove chunks of that memory again? Which zone is advised?
- Is this special standby memory on s390x that is usually not automatically
onlined?
And in short it helps to answer to some extend (excluding zone imbalances)
- Should I online this memory block?
- To which zone should I online this memory block?
... of course special use cases will result in different anwers. But that's
why user space has control of onlining memory.
More details can be found in Patch 1 and Patch 3.
Tested on x86 with hotplugged DIMMs. Cross-compiled for PPC and s390x.
Example:
$ udevadm info -q all -a /sys/devices/system/memory/memory0
KERNEL=="memory0"
SUBSYSTEM=="memory"
DRIVER==""
ATTR{online}=="1"
ATTR{phys_device}=="0"
ATTR{phys_index}==""
ATTR{removable}=="0"
ATTR{state}=="online"
ATTR{type}=="boot"
ATTR{valid_zones}=="none"
$ udevadm info -q all -a /sys/devices/system/memory/memory90
KERNEL=="memory90"
SUBSYSTEM=="memory"
DRIVER==""
ATTR{online}=="1"
ATTR{phys_device}=="0"
ATTR{phys_index}=="005a"
ATTR{removable}=="1"
ATTR{state}=="online"
ATTR{type}=="dimm"
ATTR{valid_zones}=="Normal"
RFC -> RFCv2:
- Now also taking care of PPC (somehow missed it :/ )
- Split the series up to some degree (some ideas on how to split up patch 3
would be very welcome)
- Introduce more memory block types. Turns out abstracting too much was
rather confusing and not helpful. Properly document them.
Notes:
- I wanted to convert the enum of types into a named enum but this
provoked all kinds of different errors. For now, I am doing it just like
the other types (e.g. online_type) we are using in that context.
- The "removable" property should never have been named like that. It
should have been "offlinable". Can we still rename that? E.g. boot memory
is sometimes marked as removable ...
David Hildenbrand (4):
mm/memory_hotplug: Introduce memory block types
mm/memory_hotplug: Replace "bool want_memblock" by "int type"
mm/memory_hotplug: Introduce and use more memory types
mm/memory_hotplug: Drop MEMORY_TYPE_UNSPECIFIED
arch/ia64/mm/init.c | 4 +-
arch/powerpc/mm/mem.c | 4 +-
arch/powerpc/platforms/powernv/memtrace.c | 9 +--
.../platforms/pseries/hotplug-memory.c| 7 +-
arch/s390/mm/init.c | 4 +-
arch/sh/mm/init.c | 4 +-
arch/x86/mm/init_32.c | 4 +-
arch/x86/mm/init_64.c | 8 +--
drivers/acpi/acpi_memhotplug.c| 16 -
drivers/base/memory.c | 60 ++--
drivers/hv/hv_balloon.c | 3 +-
drivers/s390/char/sclp_cmd.c | 3 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory.h| 69 ++-
include/linux/memory_hotplug.h| 18 ++---
kernel/memremap.c | 6 +-
mm/memory_hotplug.c | 29
17 files changed, 194 insertions(+), 56 deletions(-)
--
2.17.2
