Bug 179086

Summary: fork() slow when shm attached to process
Product: Red Hat Enterprise Linux 4 Reporter: Bastien Nocera <bnocera>
Component: kernelAssignee: Larry Woodman <lwoodman>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: csnook, jbaron
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-19 19:22:24 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:
Bug Depends On:    
Bug Blocks: 170416    

Description Bastien Nocera 2006-01-27 09:45:25 UTC
kernel-2.6.9-22.0.1.EL

The fork() call time grows linearly based on amount of SysV memory attached to
the process.

Fix available upstream:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d992895ba2b27cf5adf1ba0ad6d27662adc54c5e

Upstream discussion:
http://groups.google.com/group/linux.kernel/browse_thread/thread/937a999061644f1d/be39ede8f991e847

Comment 1 Chris Snook 2006-03-02 23:23:55 UTC
Support has received calls from customers of Ontario Systems, who recommend
running kernels with the lazy fork patch.  For apps that use large shared memory
spaces and fork to service each request, the performance impact can be orders of
magnitude.

The downside is that it's possible to have an OOM condition when the app
accesses a new part of the shared segment and the kernel needs to copy a PTE, a
very long time after the fork itself, thus hiding the cause.  If we implement
this, we should at least add an appropriate error message in oom-killer as well.

Comment 2 Jason Baron 2006-04-19 19:22:24 UTC

*** This bug has been marked as a duplicate of 185386 ***