Thread (65 messages) flat view 65 messages, 11 authors, 2017-10-24

Re: [RFC PATCH 3/3] mm/map_contig: Add mmap(MAP_CONTIG) support

From: David Nellans <hidden>
Date: 2017-10-23 15:27:46
Also in: linux-mm, lkml

On 10/16/2017 12:42 PM, Michal Hocko wrote:
On Mon 16-10-17 11:00:19, Cristopher Lameter wrote:
quoted
On Mon, 16 Oct 2017, Michal Hocko wrote:
quoted
That being said, the list is far from being complete, I am pretty sure
more would pop out if I thought more thoroughly. The bottom line is that
while I see many problems to actually implement this feature and
maintain it longterm I simply do not see a large benefit outside of a
very specific HW.
There is not much new here in terms of problems. The hardware that
needs this seems to become more and more plentiful. That is why we need a
generic implementation.
It would really help to name that HW and other potential usecases
independent on the HW because I am rather skeptical about the
_plentiful_ part. And so I really do not see any foundation to claim
the generic part. Because, fundamentally, it is the HW which requires
the specific memory placement/physically contiguous range etc. So the
generic implementation doesn't really make sense in such a context.
There are TLB's in AMD Xen that can take advantage of contig memory to
improve TLB coverage.  AFAIK contig is not functionally required, its
purely a performance optimization.  Current Xen TLB implementation
doesn't support arbitrary contig lengths, page sizes, etc, but its a
start.  This
type of TLB optimization can be handled on the back end by de-fragging
phys mem (when possible) now that both base and THPs can be easily
migrated; no need for up-front contig, but defrag isn't free either.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help