From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4464ADB8.9080901@lanl.gov> Date: Fri, 12 May 2006 09:46:00 -0600 From: Ronald G Minnich User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [9fans] [Fwd: [olpc-software] Multi-protection VMAs and memory usage] Topicbox-Message-UUID: 50e2ea12-ead1-11e9-9d60-3106f5b1d025 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. "