Re: spawning (exec*/wait) shows non-constant time if memory grows

[Dirk Bächle <tshortik at gmx dot de>]

Hi Siddhesh,

thank you very much for your quick reply.Your infos have been very helpful.

On 24.01.2014 12:34, Siddhesh Poyarekar wrote:
> On 23 January 2014 23:50, Dirk Bächle <tshortik@gmx.de> wrote:
> > Hi there,
> >
> > I've already posted my actual question to the kernel-dev mailing list at:
> >
> >    https://lkml.org/lkml/2014/1/14/632
> The link seems to be broken.  It just shows a blank LKML template page.
>
> > , but got no reaction so far. So I'd really appreciate if someone
> > knowledgeable could have a look at my findings and confirm to me that the
> > problem I see is a kernel issue...and not related to the glibc itself.
> > What it's basically about is: I spawn a large number of simple child
> > processes sequentially (they don't run in parallel!) while letting the
> > memory of the parent process go up with malloc(). Over the number of spawned
> > processes the runtime for each execve/wait seems to grow, which is not what
> > I would expect.
> If the memory footprint of the parent process increases, the time
> taken to clone it will increase as well since it has to clone the
> parent address space.  We don't have a light-weight exec* syscall
> similar to the Windows CreateProcess() functionality yet, where one
> would not bother cloning the parent address space only to throw it
> away in an exec.  I believe there were discussions about it in the
> past on the libc-alpha mailing list.

I patched my test program and created some new numbers for

Allocating all memory in advance, in single blocks of length SIGLEN:
--------------------------------------------------------------------

time   |  cycles
----------------

  1.94     2000
  5.15     4000
 15.27     8000
 51.11    16000
144.59    32000


Allocating all memory in advance, at once (cycles*SIGLEN):
----------------------------------------------------------

time   |  cycles
----------------

  1.27     2000
  2.66     4000
  5.27     8000
 10.70    16000
 21.40    32000

So, the memory fragmentation seems to be the key when copying the parent 
address space. Can you give me a pointer to where this happens in the 
source code? I'd like to have a look at this.

I also tried to find some older discussions in the glibc-alpha list, but 
my search so far didn't show any good results. Can someone give an exact 
link or a few keywords to search for? That'd be awesome...

Regards,

Dirk