Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: [OT] fork() 50 times slower on some Linux kernels? |
| Date | 2012-01-10 00:22 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <20120109155758.180@kylheku.com> (permalink) |
| References | <20147768-1b78-4ac5-84e5-607c1d47c6a6@dp8g2000vbb.googlegroups.com> <jefong$a4q$1@dont-email.me> <20120109140729.280@kylheku.com> <jefso9$8mo$1@dont-email.me> <9n1d6nFuu9U1@mid.uni-berlin.de> |
On 2012-01-09, Jens Thoms Toerring <jt@toerring.de> wrote: > Kaz, sorry for the "[OT]" but I prefer it that way;-) > > Stephen Sprunk <stephen@sprunk.org> wrote: >> > In any case, did you notice in the original posting that this 1 second >> > pause occurs on a system with 8GB of RAM? > >> That is apparently how long it takes for the kernel on his system to >> find backing for all those pages. I suspect that delay is why >> overcommitment is on by default. > > I now see what you meant in you're earlier post, but - as a > completely unscientific experiment - switching off overcom- > mitment doesn't seem to make any difference on my system. Finding backing for pages happens during the memset operation, whereas what is being timed is the call to system(). Even with strict accounting, fork should not be duplicating the pages and committing memory for them, but be implementing a copy-on-write optimization. Strict accounting would mean that fork should fail if creating the (empty!) maps for the process would bring the total VM footprint of the system over the limit. That's the theory. Where that 1 second is being spent is anyone's guess. Maybe that kernel has a patch that causes fork not to do copy-on-write. I would start by running the test case using "strace -f -r <command>" (with -f to follow forks and -r to print relative timestamps). This will reveal which syste call(s) are spending that time. system() is not a system call, but pretty complicated function which does a fork, exec and wait and probably mucking around with file descriptors and probably signal handling and such.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
fork() 50 times slower on some Linux kernels? Elmar <elmar.krieger@gmail.com> - 2012-01-09 12:25 -0800
Re: fork() 50 times slower on some Linux kernels? Ian Collins <ian-news@hotmail.com> - 2012-01-10 09:41 +1300
Re: fork() 50 times slower on some Linux kernels? Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 21:32 +0000
[OT] Re: fork() 50 times slower on some Linux kernels? jt@toerring.de (Jens Thoms Toerring) - 2012-01-09 22:12 +0000
Re: [OT] Re: fork() 50 times slower on some Linux kernels? Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 22:32 +0000
Re: [OT] Re: fork() 50 times slower on some Linux kernels? Ian Collins <ian-news@hotmail.com> - 2012-01-10 11:56 +1300
Re: fork() 50 times slower on some Linux kernels? Stephen Sprunk <stephen@sprunk.org> - 2012-01-09 16:11 -0600
Re: fork() 50 times slower on some Linux kernels? Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 22:30 +0000
Re: fork() 50 times slower on some Linux kernels? Stephen Sprunk <stephen@sprunk.org> - 2012-01-09 17:20 -0600
Re: [OT] fork() 50 times slower on some Linux kernels? jt@toerring.de (Jens Thoms Toerring) - 2012-01-09 23:57 +0000
Re: [OT] fork() 50 times slower on some Linux kernels? Kaz Kylheku <kaz@kylheku.com> - 2012-01-10 00:22 +0000
Re: [OT] fork() 50 times slower on some Linux kernels? Stephen Sprunk <stephen@sprunk.org> - 2012-01-09 20:39 -0600
Re: [OT] fork() 50 times slower on some Linux kernels? William Ahern <william@wilbur.25thandClement.com> - 2012-01-09 19:43 -0800
Re: [OT] fork() 50 times slower on some Linux kernels? Stephen Sprunk <stephen@sprunk.org> - 2012-01-10 00:31 -0600
Re: fork() 50 times slower on some Linux kernels? Elmar <elmar.krieger@gmail.com> - 2012-01-11 14:39 -0800
Re: fork() 50 times slower on some Linux kernels? Nobody <nobody@nowhere.com> - 2012-01-10 23:07 +0000
csiph-web