Date: Mon, 23 Jun 2003 19:27:22 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: "D. J. Bernstein" <djb@cr.yp.to> Cc: freebsd-performance@freebsd.org Subject: Re: ten thousand small processes Message-ID: <20030623190019.G36168-100000@mail.chesapeake.net> In-Reply-To: <20030621185821.30070.qmail@cr.yp.to>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Jun 2003, D. J. Bernstein wrote: > FreeBSD 4.8. Test program: malloc(360); malloc(80); malloc(180); > malloc(16); malloc(440); sleep(10); _exit(0). Compile statically. > > The program ends up with 44KB RSS. Where is all that DRAM going? The > program also ends up with 168KB VSZ. Where is all that VM going? > > I don't care much about the 3-page text segment. But I do care about the > 39 extra pages of VM, and the 8 extra pages of DRAM. There's no obstacle > to having a small program fit into _one_ page per process; two or three > can be excused, but 39 is absurd. (Yes, I know that Solaris is worse.) Even small programs need page tables. On x86 unix you need at least pages for page tables for any process, if I'm counting correctly. One for the page directory, one page table for text, data, bss, and the guard page, and one page table page for stack. 32 of those 'pages of VM' are your initial stack size. They don't really consume any resources other than preventing anyone else from allocating overlapping pages. It's just the initial upper limit on the stack map which is allowed to grow. I haven't looked closely enough to find out what the other 7 might be. There is an obstacle to having a small program fit into one page. Actually, a significant one. First of all, you need protections on different sections of the actual executable image. Text must be read only since it is shared. Data is read write and bss is read-write. BSS is a pseudo section and not actually mapped from the file. Text and data both can be paged in from the binary in a demand paged system such as freebsd. Data can not be written out to its backing object and neither can text. Text can be shared while data changes are private and so the two must be placed in seperate pages. This topic is explored quite well in any modern operating systems book. I suggest you pick up "The Design and Implementation of the 4.4BSD Operating System". It is a little out dated but provides a good introduction to these topics. I really didn't do them justice with this paragraph. If demand paging, shared libraries, and the like are not suited for your problem perhaps you should look at an embedded operating system? Or DOS even. Cheers, Jeff > > At least 2 pages appear to be wasted by exit(), because it brings in a > chunk of stdio, which uses 84 bytes of data and 316 bytes of bss. The > libc implementors clearly don't care about 316 bytes of memory, so why > don't they make those 316 bytes static? Why doesn't the compiler > automatically merge some bss into data when that saves a page? Why can't > I omit exit(), manually or automatically, when it's unreachable? > > Furthermore, malloc() appears to chew up a whole new page of DRAM for > each allocation, plus another page---is this counted in VSZ?---for an > anonymous mmap. Would it really be that difficult to fit 1076 bytes of > requested memory into the 3000-odd bytes available at the end of bss? > > I sure hope that there's some better explanation for the remaining 32 > pages than ``Well, we decided to allocate 131072 bytes of memory for the > stack,'' especially when I'm hard-limiting the stack to 4K before exec. > > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030623190019.G36168-100000>