On Wed, Nov 20, 2002 at 06:02:30PM -0800, David Schultz wrote:
> Thus spake Tony Finch <[EMAIL PROTECTED]>:
> >
> > Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
> > programs they should be mostly shared. See rtld-elf/map_object.c
>
> Once those pages are written to,
Thus spake Mike Silbersack <[EMAIL PROTECTED]>:
> I'm curious how well COW sharing really works under FreeBSD. Earlier this
> year, I fixed a piece of code which was O((processes sharing a page)^2) in
> the VM system. When certain simple forkbombs were run, they would cause
> the machine to freez
Thus spake Tony Finch <[EMAIL PROTECTED]>:
> David Schultz <[EMAIL PROTECTED]> wrote:
> >
> >BSS and modified data are not shared, and Matt is only counting
> >zero fill and COW faults.
>
> Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
> programs they should be mostly
On Wed, 20 Nov 2002, Tony Finch wrote:
> David Schultz <[EMAIL PROTECTED]> wrote:
> >
> >BSS and modified data are not shared, and Matt is only counting
> >zero fill and COW faults.
>
> Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
> programs they should be mostly sha
David Schultz <[EMAIL PROTECTED]> wrote:
>
>BSS and modified data are not shared, and Matt is only counting
>zero fill and COW faults.
Most of the BSS is mmapped zero pages that are copy-on-write, so in simple
programs they should be mostly shared. See rtld-elf/map_object.c
Tony.
--
f.a.n.finch
Thus spake Gary Thorpe <[EMAIL PROTECTED]>:
> > Take /bin/csh (aka tcsh) for example.
> >
> > Startup overhead if static: 144 pages faults, 113 zero fill, 64
> > COW
> > Startup overhead if dynamic: 310 page faults, 131 zero fill, 84
> > COW
> >
> > So the difference is 38 pag
:I just ran a quick test on my systems here. It looks like two
:identical systems give results that are approximately:
:
: VSZ RSS
:dynamic:
:root 79054 1.3 2.5 1952 1524 pa S 2:56AM 0:00.13 tcsh
:static:
:root 38788 0.0 0.1 1324 908 pi S 7:53PM 0:00.0
:>
:> So the difference is 38 pages of memory = 152KB per instance.
:> That's fairly significant on a multi-user system that might have
:> several hundred csh's running. I specifically compile certain
:> non-forked binaries on my system static precisely to reduce their
:> me
--- Matthew Dillon <[EMAIL PROTECTED]> wrote:
> :I personally thing that we should have a shared /{s,}bin in 5.0 and
> :that it should be the dafult and that it should work with / and /usr
> :being on different partitions. Preliminary indications are that
> we'd
> :save on the order of 25M-30M on
In message: <[EMAIL PROTECTED]>
Matthew Dillon <[EMAIL PROTECTED]> writes:
: Take /bin/csh (aka tcsh) for example.
:
: Startup overhead if static: 144 pages faults, 113 zero fill, 64 COW
: Startup overhead if dynamic: 310 page faults, 131 zero fill, 84 COW
:
: So
:I personally thing that we should have a shared /{s,}bin in 5.0 and
:that it should be the dafult and that it should work with / and /usr
:being on different partitions. Preliminary indications are that we'd
:save on the order of 25M-30M on /, which makes up for the additional
:kernel modules we
In message: <[EMAIL PROTECTED]>
Matthew Dillon <[EMAIL PROTECTED]> writes:
: I think that should be a goal. I think something like this:
:
: USE_MINIC=YES Link against the mini-C library.
I don't like this so much, but not enough to object to it be allowed,
but not defaul
This should really be on hackers, not cvs-committers. I have
redirected the Cc.
:I don't think that a mini-c will help at all. /bin can be scrunched
:down to 500k and sbin to 605k on 4.5 and the system will still boot.
:A full install is only 2842k when sbin/bin are dynamically linked.
This is not finished yet, but it's good enough to start shipping patches.
Note that libminic currently installed in /usr/lib, not in /lib. I
haven't gotten to that part yet. I also did not spend a huge amount
of time trying to cut the size down. I dealt with locale, malloc, and
On Fri, 15 Nov 2002, Alfred Perlstein wrote:
> * Matthew Dillon <[EMAIL PROTECTED]> [021115 12:17] wrote:
> > :Will the knobs allow one to link /bin and /sbin against full blown
> > :libc? That would be nice as we can then start using pam and user
> > :management in / with dynamic modules (finally
* Matthew Dillon <[EMAIL PROTECTED]> [021115 12:17] wrote:
> :Will the knobs allow one to link /bin and /sbin against full blown
> :libc? That would be nice as we can then start using pam and user
> :management in / with dynamic modules (finally!).
> :
> :--
> :-Alfred Perlstein [[EMAIL PROTECTED
:Will the knobs allow one to link /bin and /sbin against full blown
:libc? That would be nice as we can then start using pam and user
:management in / with dynamic modules (finally!).
:
:--
:-Alfred Perlstein [[EMAIL PROTECTED]]
I think that should be a goal. I think something like this:
* Matthew Dillon <[EMAIL PROTECTED]> [021115 11:25] wrote:
> :Time Kientzle has offered to build something similar to NetBSD's dynamic
> :/[s]bin and lukem has sent us some info on his work. Let me know if
> :anyone is duplicating effort here.
> :
> :-Nate
>
> I've made really excellent progr
:Time Kientzle has offered to build something similar to NetBSD's dynamic
:/[s]bin and lukem has sent us some info on his work. Let me know if
:anyone is duplicating effort here.
:
:-Nate
I've made really excellent progress. I moved my link line adjustments
to /usr/src/share/mk/bsd.prog.
On Thu, 14 Nov 2002, Alfred Perlstein wrote:
> * Nate Lawson <[EMAIL PROTECTED]> [021114 15:42] wrote:
> > Please see earlier threads on hackers@ about bloat in libc and dynamic
> > linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's
> > dependency on malloc which saves space in
I have sucessfully created a mini-C-like library and
compiled /bin/sleep against it. (This is in stable,
by the way, so its still a bit bigger then it needs to be).
My minic library is:
apollo:/usr/src/lib/libminic# ls -la
total 30
drwxr-xr-x 2 root wheel 512 Nov 15 02:17 .
drwx
The only problem with libstand is that it is not really designed
to link against normal programs. There are a lot of shims in there
to simulate system calls, like lseek() and sbrk().
But I don't see why we couldn't create a mini-c library that is based
on the portable pieces o
:I'd like to see / dynamically linked with some form of /stand that gets
:updated in case of emergencies.
:
:When/who is going to do this already? :)
:
:-Alfred
libstand seems to have a most of what we would need. It has getopt,
most of the str*() functions (imported from libc), and mallo
:>borrowed from libc), sufficient for simple binaries. It could be made
:>compatible with our standard includes (structural bloat != code bloat,
:>so who cares).
:
:I think Nate's got a good point regarding maintainability here. If we
:do want to create a mini-libc, we need to minimi
[This doesn't belong in cvs-all and Nate has already made comments in
-hackers]
On 2002-Nov-14 14:57:39 -0800, Matthew Dillon <[EMAIL PROTECTED]> wrote:
>I think the real issue is the bloat in libc. printf() eats 20K, basic
>stdio eats 5K. You get 15K of bloat just with a blank main(),
* Nate Lawson <[EMAIL PROTECTED]> [021114 15:42] wrote:
> Please see earlier threads on hackers@ about bloat in libc and dynamic
> linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's
> dependency on malloc which saves space in the programs that don't
> otherwise use malloc.
>
>
Please see earlier threads on hackers@ about bloat in libc and dynamic
linking of /[s]bin. Tim Kientzle submitted a patch that breaks exit's
dependency on malloc which saves space in the programs that don't
otherwise use malloc.
I don't think a mini-libc is a good idea because bugfixes would need
27 matches
Mail list logo
