[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [lvm-devel] lvm and locales memory issue

On 23.2.2010 17:28, Jakub Jelinek wrote:
> On Tue, Feb 23, 2010 at 04:17:39PM +0100, Zdenek Kabelac wrote:
>> It looks like cs_CZ.utf8/LC_MESSAGES/SYS_LC_MESSAGES  is just 59 bytes.
>> There is something seriously wrong with the current glibc optimalization to
>> have 100MB locked into memory if you want to use 59 bytes from this file....
> LC_MESSAGES contains just yesstr/nostr definition, nothing else.
> But guess your application isn't asking just for LC_MESSAGES category...

But that's exactly what we actually need for our lvm.
Translated error messages...

>> Looking at the size of /usr/share/i18n/locales/cs_CZ - one may start to wonder
>> why Czech locales are defining collates for arabic latin and other 'related'
>> laguages, while in German there is simple 'copy "iso14651_t1"'
> iso14651_t1 defines collation for all kinds of charsets, ideally cs_CZ
> should just include that file too and tweak afterwards for the differences
> Czech ordering requires.

And where is the problem to handle that this way ?

>> Another note could be - Ubuntu does not even use locale-archive file and uses
>> locales on per file basis - so now I'm getting curious, where are the tests,
> Not everything Ubuntu does is necessarily a good idea.
>> that proves that Fedora gets some measurable performance advantage?

> Try something trivial, like:
> #include <locale.h>

Yeah - typical real world application...

Anyway all we want to achive here is - to have a choice - if application is
using mlockall() it should be able to select less memory demanding way of
handling locales - whole code is already there and imho needs just a little
tweaking around.

Thus glibc could still handle millions of setlocale switches per second for
typical Fedora user which surely appreciate this worthy optimization for 100MB
disk space - but if the application needs - it should be able to select a
method - which allow only thousands of switches - but will fit into few
hundreds kb of memory space for mlockall().


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]