Description of problem:

For majority of application using mmap-ed file is actually not a problem as only tiny fraction of such file takes some memory (i.e.. typically in range of tens KB)

However problem is, when application wants to lock itself in memory.

Please check the original problem in bug 541911.  

If the application uses mlockall() then whole 100MB file (on my current rawhide distro) gets mmaped to memory and eats memory if some locales are set for such application.

Current solution for dmeventd is to either not setup locales inside the application or to switch them to plain C before application startup (as after all the binary itself is not really localized at this moment anyway)

But this effectively makes any application that wants to use mlockall() (for whatever reason) hardly 'localizable' - as locking 100MB of mostly junk into system memory is not really a good option in this case.

I'm not really sure what is the right solution here:

- maybe split the locale-archive to smaller files per language ?
- eventually at least support selectable locales for whole system, so the file has only locales which makes sense on given system - thus file is much much smaller ?
- or leave the current status and mark program that uses mlockall() non-localizable ?

Version-Release number of selected component (if applicable):
glibc-common-2.11.90-4.x86_64

How reproducible:


Steps to Reproduce:
1. use dmeventd (device-mapper-event-1.02.38-2.fc12.x86_64) with some locales 
2.
3.
  
Actual results:
lots of resident memory taken by mlocked /usr/lib/locale/locale-archive

Expected results:


Additional info: