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

From: Pavel Machek
Date: Mon Oct 16 2017 - 05:54:54 EST


On Mon 2017-10-16 10:18:04, Michal Hocko wrote:
> On Sun 15-10-17 08:58:56, Pavel Machek wrote:
> > Hi!
> >
> > > Yes you wrote that already and my counter argument was that this generic
> > > posix interface shouldn't bypass virtual memory abstraction.
> > >
> > > > > > The contiguous allocations are particularly useful for the RDMA API which
> > > > > > allows registering user space memory with devices.
> > > > >
> > > > > then make those devices expose an implementation of an mmap which does
> > > > > that. You would get both a proper access control (via fd), accounting
> > > > > and others.
> > > >
> > > > There are numerous RDMA devices that would all need the mmap
> > > > implementation. And this covers only the needs of one subsystem. There are
> > > > other use cases.
> > >
> > > That doesn't prevent providing a library function which could be reused
> > > by all those drivers. Nothing really too much different from
> > > remap_pfn_range.
> >
> > So you'd suggest using ioctl() for allocating memory?
>
> Why not using standard mmap on the device fd?

No, sorry, that's something very different work, right? Lets say I
have a disk, and I'd like to write to it, using continguous memory for
performance.

So I mmap(MAP_CONTIG) 1GB working of working memory, prefer some data
structures there, maybe recieve from network, then decide to write
some and not write some other.

mmap(sda) does something very different... Everything you write to
that mmap will eventually go to the disk, and you don't have complete
control when.

Also, you can do mmap(MAP_CONTIG) and use that to both disk and
network. That would not work with mmap(sda) and mmap(eth0)...

Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: Digital signature