Bug 218865 - setlocale more effecient on 32bit platforms then 64bit
Summary: setlocale more effecient on 32bit platforms then 64bit
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.4
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-12-07 21:44 UTC by Kenneth Topp
Modified: 2016-11-24 15:25 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-12-07 22:03:05 UTC

Attachments (Terms of Use)

Description Kenneth Topp 2006-12-07 21:44:19 UTC
on 64bit, if you are using locale-archive, there's nothing you can do from
mmap'ing the entire file, where on 32bit, it seems to just get what it needs.

using glibc-2.3.4-2.13

32bithost# for i in C en_US.UTF-8 ja_JP.eucjp; do  echo == lang = $i ==; echo
'pmap $$' | env LANG=$i ksh | egrep locale-archive\|total;done
== lang = C ==
 total     2576K
== lang = en_US.UTF-8 ==
b7df8000   2048K r----  /usr/lib/locale/locale-archive
 total     4656K
== lang = ja_JP.eucjp ==
b7d1d000    876K r----  /usr/lib/locale/locale-archive
b7df8000   2048K r----  /usr/lib/locale/locale-archive
 total     5656K

64bithost# for i in C en_US.UTF-8 ja_JP.eucjp  ; do  echo == lang = $i ==; echo
'pmap $$' | env LANG=$i ksh | egrep locale-archive\|total;done
== lang = C ==
 total            14452K
== lang = en_US.UTF-8 ==
0000002a95561000  47384K r----  /usr/lib/locale/locale-archive
 total            61868K
== lang = ja_JP.eucjp ==
0000002a95561000  47384K r----  /usr/lib/locale/locale-archive
 total            64040K

Comment 1 Jakub Jelinek 2006-12-07 22:03:05 UTC
The 64-bit variant is more efficient, it mmaps just once, while the 32-bit one
has to do that multiple times.  For 64-bit processes we have enough address
space that we can do the right thing, 32-bit address space is limited enough
that it is not possible.

Comment 2 Ulrich Drepper 2006-12-07 22:10:00 UTC
You seem to not understand the difference between "address space use" and
"memory use".  The memory use in both cases is the same since only the
respective pages containing the needed data is actually loaded.  For 64-bit we
are using a larger mapping (the whole file) which means nothing for the actual
memory use (ignore page tables).  The advantage is that the 64-bit code
accessing the file is much simpler and faster so that overall the 64-bit code
uses less memory and CPU.

On a FC6/RHEL5 system, look at /proc/PIC/smaps and observe the RSS value for the
file.  This is what I see on my system:

2aaaaaac8000-2aaaadfba000 r--p 00000000 08:12 1857788                   
Size:             54216 kB
Rss:                 40 kB
Shared_Clean:        40 kB
Shared_Dirty:         0 kB
Private_Clean:        0 kB
Private_Dirty:        0 kB

Out of the 54M file only 40k are actually in memory.

Note You need to log in before you can comment on or make changes to this bug.