On Wed, Nov 21, 2012 at 9:13 PM, Ramana Radhakrishnan <ramra...@arm.com> wrote: > 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 ? They are used to do padding in structures to avoid false sharing. > > 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 ? I've heard someone complain about this recently. glider? Running asan on *huge* binaries in 32-bit address space is a challenge indeed. My suggestion was to link with -pie. --kcc > Turning off > address space randomization doesn't seem to help either. > > regards, > Ramana > >
