This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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/632The 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 32000So, 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |