On Mon, 11 May 2015 10:36:18 -0400 Eric B Munson <emunson@xxxxxxxxxx> wrote: > On Fri, 08 May 2015, Andrew Morton wrote: > ... > > > > > Why can't the application mmap only those parts of the file which it > > wants and mlock those? > > There are a number of problems with this approach. The first is it > presumes the program will know what portions are needed a head of time. > In many cases this is simply not true. The second problem is the number > of syscalls required. With my patches, a single mmap() or mlockall() > call is needed to setup the required locking. Without it, a separate > mmap call must be made for each piece of data that is needed. This also > opens up problems for data that is arranged assuming it is contiguous in > memory. With the single mmap call, the user gets a contiguous VMA > without having to know about it. mmap() with MAP_FIXED could address > the problem, but this introduces a new failure mode of your map > colliding with another that was placed by the kernel. > > Another use case for the LOCKONFAULT flag is the security use of > mlock(). If an application will be using data that cannot be written > to swap, but the exact size is unknown until run time (all we have a > build time is the maximum size the buffer can be). The LOCKONFAULT flag > allows the developer to create the buffer and guarantee that the > contents are never written to swap without ever consuming more memory > than is actually needed. What application(s) or class of applications are we talking about here? IOW, how generally applicable is this? It sounds rather specialized.
