On 03/10/2014 06:55 AM, Aurelien Jarno wrote:
On Tue, Mar 04, 2014 at 12:24:23AM +0200, Aaro Koskinen wrote:
Hi,
On Mon, Mar 03, 2014 at 02:06:18PM +0000, Markos Chandras wrote:
Are you referring to programs hard coding the page size to 4k instead of
using the getpagesize()? Well yes this could be a problem. But is that a
real problem? We are changing the default value so whoever has such an old
userland can easily switch to the 4k page size. It may also be a good
opportunity to expose such application and get the fixed properly :) But if
that's not acceptable, we can drop the patch. Paul what do you think?
Not so long ago there was an issue with Debian where Iceweasel or
Spidermonkey failed on MIPS/Loongson because of its 8K page size (the
userspace assumed 4K). You will get such issues as long as x86 dominates,
it's not a matter of "old userland".
In Debian I am aware of the problem on at least all mozilla based
products (the problem is jemalloc) and GCL.
The problem is not that the page size is hardcoded to 4K, but that it is
detected at build time instead of run time.
Of course that is incorrect, pagesize must be detected at runtime. Any
package that does otherwise is defective and should be fixed.
If they need an upper bound, we can supply that. It is 64K.
This is only a problem for
distributions where a package could be built on one machine and run on
another, but it should not affect people building such packages
themselves, or using the same set of machines.
The fact that the page size is not 4K is usually correctly handled, as
other architectures like alpha and itanium were using 8K or 16K pages.
