Bug 435721

Summary:	mmap may keep mmap_sem for a long time
Product:	Red Hat Enterprise MRG	Reporter:	Roland Westrelin <roland.westrelin>
Component:	realtime-kernel	Assignee:	Red Hat Real Time Maintenance <rt-maint>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	low
Version:	1.0	CC:	bhu, pzijlstr, williams
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-05 21:06:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Roland Westrelin 2008-03-03 15:27:37 UTC

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:

Comment 1 Peter Zijlstra 2008-09-30 17:42:08 UTC

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?

Comment 2 Beth Uptagrafft 2009-09-22 20:03:04 UTC

There has been no recent activity on this issue. Is this still a problem?