Re: locale files and page size

[Roland McGrath <roland at hack dot frob dot com>]

AIUI the point of the alignment is to take best advantage of locality.
The loading code maps whole pages (of course), so it's ideal if any
page you need to see is filled with other things you will need to see
eventually.  Hence the logic to group the categories whose data sizes
are small together into a page.

Note that LP64 configurations always map the whole file in, so the
question is moot there.  The important corollary is that any changes
in this area need thorough testing on both at least one LP64 and at
least one ILP32 configuration.

So, I think the optimization does make sense at all.  But I'm not
really sure it's the case that it matters that much that it use the
right page size.  The LCD page size (i.e. 4k) might be good enough in
practice for everybody.

It's also not very clear that it does enough good to warrant the
complexity in localedef.  For one thing, before it gets to the clever
stuff, it always just maps the leading 2M of the file with the
expectation that this will contain all the data for the most
commonly-used locale (i.e. the one added to the archive first).

If one wanted to be thorough, one could model the loadarchive.c code's
mapping behavior and do some analysis.  For a given page size and set
of (locale, category) pairs, the model yields the number of pages that
need to be mapped from a given archive layout.  Then one can run this
model over various archives (varying the in-file alignment size, the
reader's page size, and the set and order of locales added to the
archive).

It would be great to see someone do that analysis and produce some
interesting data.  But that's a lot of work for a pretty small issue.
We know that the most common affected configurations (i.e. ILP32 with
4k pages) will be unchanged by just hard-coding the in-file alignment
to 4k in localedef.  So I would not object to doing that in the
absence of actual analysis.


Thanks,
Roland