On 11/21/12 16:27, Andrew Pinski wrote:
On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany
<konstantin.s.serebry...@gmail.com> wrote:
On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner <berg...@vnet.ibm.com> wrote:
On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote:
On Wed, Nov 21, 2012 at 7:29 PM, David Miller <da...@davemloft.net> wrote:
From: Konstantin Serebryany <konstantin.s.serebry...@gmail.com>
Date: Wed, 21 Nov 2012 17:39:05 +0400
Today, kPageSize is used in several places where it is expected to be
a compile-time constant.
Even if it seems like replacing it with GetPageSize() is safe, it
would need very significant testing (including performance testing).
Can we just define kPageSize=1UL<<13 under ifdef __sparc__?
What are the possible page size values for SPARC?
4K, 8K, 64K, 512K
It's not a constant and the library really cannot expect it to be one.
How often 64K and 512K are used?
If we use kPageSize=8K, will this cover most of the use cases?
To answer this for PowerPC, most current 64-bit distro kernels are
compiled with 64K pages, although some older kernel still out there
are compiled with 4K pages. For 32-bit kernels, I believe they
usually default to 4K pages. As with SPARC, the kernel can be
configured to use any number of different page sizes.
An 8K page size won't work for us or a SPARC system with page size
above 8K, since the minimum mmap size is a page size, so if you
attempt to mmap something smaller than a page size (eg, 8K on a
64K page size system), mmap returns an error. If this stays a
constant, you have to err on the large side of the potential
page sizes.
I agree with David, that this has to be runtime generated value.
I'll play with his GetPageSize() suggestion and see whether it
works for us.
We'll need to be very careful with such change (e.g. there are other
constants defined using kPageSize,
there are other places where it is used in performance critical code).
And such change should go only via upstream.
Maybe we can solve the problem by changing kMmapGranularity? (On
Win32, we have 4k pages but larger kMmapGranularity)
Changing kMmapGranularity to a non-constant is much less intrusive.
Just to follow up, MIPS64 have the following (selectable at kernel
compile time) page sizes:
4k, 8k, 16k, 32k and 64k.
And ... AArch allows for 4k and 64k page sizes, AArch64 currently
supports both 4k and 64k page sizes in the Linux kernel, AArch32 (ARM
GNU/Linux) currently supports only 4K.
I also notice that you've hard coded cache line size. Why is that
necessary and what's it used for ?
While trying to add support for ARM (AArch32 GNU / Linux) implementation
for GCC after-hours but still keep seeing failures on my chromebook
running an ubuntu fs on a ChrOS kernel, because the shadow memory
apparently overlaps with normal memory. Has anyone else hit this while
porting ? Turning off address space randomization doesn't seem to help
either.
regards,
Ramana
