Re: [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 19 Apr 2017, Balbir Singh wrote:

> The first patch defines N_COHERENT_MEMORY and supports onlining of
> N_COHERENT_MEMORY.  The second one enables marking of coherent

The name is confusing. All other NUMA nodes are coherent. Can we name this
in some way that describes what is special about these nodes?

And we already have support for memory only nodes. Why is that not sufficient?
If you can answer that question then we may get to the term to be used to
name these nodes. We also have support for hotplug memory. How does the
memory here differ from hotplug?

 > memory nodes in architecture specific code, the third patch
> enables mempolicy MPOL_BIND and MPOL_PREFERRED changes to
> explicitly specify a node for allocation. The fourth patch adds

Huh? MPOL_PREFERRED already allows specifying a node.
MPOL_BIND requires a set of nodes. ??

> 1. Nodes with N_COHERENT_MEMORY don't have CPUs on them, so
> effectively they are CPUless memory nodes
> 2. Nodes with N_COHERENT_MEMORY are marked as movable_nodes.
> Slub allocations from these nodes will fail otherwise.

Isnt that what hotpluggable nodes do already?

> 1. MPOL_BIND with the coherent node (Node 3 in the above example) will
> not filter out N_COHERENT_MEMORY if any of the nodes in the nodemask
> is in N_COHERENT_MEMORY
> 2. MPOL_PREFERRED will use the FALLBACK list of the coherent node (Node 3)
> if a policy that specifies a preference to it is used.

So this means that "Coherent" nodes means that you need a different
fallback mechanism? Something like a ISOLATED_NODE or something?

The approach sounds pretty invasive to me. Can we first clarify what
features you need and develop terminology that describes things in terms
of a view from the Linux MM perspective? Coherent memory is nothing
special from there. It is special from the perspective of offload devices
that have heretofore not offered that. So its mainly a marketing term. We
need something descriptive here.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux