[9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory usage]

[9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory usage]

[Ronald G Minnich]

Just got this from the OLPC list. Another reason to love shared 
libaries. Are things getting kludgy here or what ...


=====
LWN lwn.net had an article this week discussing a patch that can
result is some nice memory savings for 'multi-protection VMAs'

Here is a link the relevant kernel mailing list thread

http://thread.gmane.org/gmane.linux.kernel/402675

and here is an excerpt from the lwn article,

"Ordinary Linux users could also benefit from this patch, however.
Ulrich Drepper explained how the C library uses VMAs currently; it
turns out that linking to a single shared library can create up to
five separate VMAs. An application which brings in a large number of
libraries - as many desktop applications do - can end up creating
hundreds of VMAs for shared library mappings. That leads to many VMAs
being created on the system; just how many can be seen by looking at
the vm_area_struct line in /proc/slabinfo. Your editor's system
currently has over 13,000 VMAs active, using about 2.5MB of memory.

Of the five VMAs potentially created by glibc for each shared library
mapping, four are mappings into the same file with different
permissions. The ability to have multiple permissions settings within
a single VMA has the potential to collapse those four VMAs into one,
leaving a single file mapping and an anonymous memory segment for each
library. The result would be significantly reduced memory usage and
faster kernel performance. Those benefits are likely to motivate the
inclusion of this patch, sooner or later. "

Re: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory

[quanstro]

isn't wrong to blame shared libraries for this?  don't misunderstand --- shared
libraries have plenty of drawbacks --- but this seems at first glance to be a problem with
the crossproduct of bloated applications and glibc badness?

and yes, things are getting kludgy.

- erik

> Just got this from the OLPC list. Another reason to love shared 
> libaries. Are things getting kludgy here or what ...
> 
> 

Re: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory usage]

[David Leimbach]

I love the Video Music Awards too...  and all other 3 letter acronyms

On 5/12/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> Just got this from the OLPC list. Another reason to love shared
> libaries. Are things getting kludgy here or what ...
>
>
> =====
> LWN lwn.net had an article this week discussing a patch that can
> result is some nice memory savings for 'multi-protection VMAs'
>
> Here is a link the relevant kernel mailing list thread
>
> http://thread.gmane.org/gmane.linux.kernel/402675
>
> and here is an excerpt from the lwn article,
>
> "Ordinary Linux users could also benefit from this patch, however.
> Ulrich Drepper explained how the C library uses VMAs currently; it
> turns out that linking to a single shared library can create up to
> five separate VMAs. An application which brings in a large number of
> libraries - as many desktop applications do - can end up creating
> hundreds of VMAs for shared library mappings. That leads to many VMAs
> being created on the system; just how many can be seen by looking at
> the vm_area_struct line in /proc/slabinfo. Your editor's system
> currently has over 13,000 VMAs active, using about 2.5MB of memory.
>
> Of the five VMAs potentially created by glibc for each shared library
> mapping, four are mappings into the same file with different
> permissions. The ability to have multiple permissions settings within
> a single VMA has the potential to collapse those four VMAs into one,
> leaving a single file mapping and an anonymous memory segment for each
> library. The result would be significantly reduced memory usage and
> faster kernel performance. Those benefits are likely to motivate the
> inclusion of this patch, sooner or later. "
>
>

Re: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory

[Paweł Lasek]

On 5/12/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> isn't wrong to blame shared libraries for this?  don't misunderstand --- shared
> libraries have plenty of drawbacks --- but this seems at first glance to be a problem with
> the crossproduct of bloated applications and glibc badness?

I have a strong feeling that if you kick out glibc and prepare more
sensible set of core libraries (keeping all standard-compliant
functions + things like RSBAC), most of linux badness would vanish....
:D

> and yes, things are getting kludgy.
>



-- 
Paul Lasek

Re: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Considering that glibc contains things like Sun RPC, I think that this is a
sensible approach. It would be nice if Dietlibc would become more
compliant...

On 5/16/06, Paweł Lasek <pawel.lasek@gmail.com> wrote:
>
> On 5/12/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > isn't wrong to blame shared libraries for this?  don't misunderstand ---
> shared
> > libraries have plenty of drawbacks --- but this seems at first glance to
> be a problem with
> > the crossproduct of bloated applications and glibc badness?
>
> I have a strong feeling that if you kick out glibc and prepare more
> sensible set of core libraries (keeping all standard-compliant
> functions + things like RSBAC), most of linux badness would vanish....
> :D
>
> > and yes, things are getting kludgy.
> >
>
>
>
> --
> Paul Lasek
>



-- 
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

[-- Attachment #2: Type: text/html, Size: 1948 bytes --]