Re: Sparc ASAN

[Andrew Pinski <pinskia at gmail dot com>]

On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner <bergner@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 <davem@davemloft.net> wrote:
>>> > From: Konstantin Serebryany <konstantin.s.serebryany@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.  So is another target where the page size is
not constant just like PPC.  Some people use 16k page sizes if they
are also going to use huge pages too.  Some people use 64k pages if
they want good performance without huge pages (though the use of 64k
pages might be less of a performance gain with the support of
transparent huge pages).

Thanks,
Andrew

>
> --kcc
>
>>
>> Peter
>>
>>
>>
>>