Description of problem: If a process locks its virtual address space in physical memory (either with mlockall() or with the MAP_LOCKED flag of mmap), the time a call to mmap takes increases with the size of the requested mapping and can take up to several tens or hundreds of milliseconds. The whole time, mmap_sem is kept by the thread that is mmaping thus preventing any other thread that also requires the mmap_sem in the process from making progress. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
That is expected behaviour as the mmap call will have to install every page for such a mapping, therefore the time will increase linearly with the number of pages in it. What other mmap_sem users in particular are held up by this?
There has been no recent activity on this issue. Is this still a problem?