Re: remap_file_pages() use

[Jeff Smith]

On Mon, May 19, 2014 at 9:38 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Mon, May 19, 2014 at 05:35:40PM +0300, Kirill A. Shutemov wrote:
>> >From functional POV, emulation *should* be identical to original
>> remap_file_pages(), but slower. It would be nice, if you test it early.
>>
>> It's not clear yet how long emulation will be there.
>
> Stop right there.  We found out about two real life users of
> remap_file_pages() already, without even committing the patches to warn
> about using it to any tree.
>
> I think at this point the whole idea of removing the API should be dead
> on the floor, as we do not needlessly break userspace programs.
>
> If we can get rid of the ugly guts and provide a good enough emulation
> that the user won't cry I'd love to get rid of this cruft, but even
> that doesn't look certain yet.

Sorry for being late to the party, but I just noticed this proposal
via the LWN summary byline.

I wanted to comment that Kenny's use case is (I believe) quite
widespread. I've used the technique since ~2008, and I've come across
other people in subsequent jobs who independently developed the same
technique. Mirrored mapping is absolutely required by several
independent proprietary platforms I'm aware of, and remap_file_pages()
has historically been the only sane way to accomplish this. (i.e.,
shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
half).

It may not be individuals who are involved in the kernel development
scene to any great extent, but I am sure that remap_file_pages() being
deprecated would seriously piss off a lot of individuals. The pattern
has even had a section in the Wikipedia article for quite some time:
http://en.wikipedia.org/wiki/Circular_buffer#Mirroring

It would be most preferable from a user standpoint to keep the
existing system intact, but failing that, a reservation API would need
to be created (possibly a MAP_RESERVE flag) that would set aside a
region that could only be subsequently mapped via explicit
address-requesting mmap() calls.

Thanks for any consideration of these concerns.
--Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/