[aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far

[Per Liden]

On 04/15/2019 01:30 PM, Andrew Haley wrote:
> On 4/15/19 12:24 PM, Per Liden wrote:
>> On 04/15/2019 12:53 PM, Andrew Haley wrote:
>>> On 4/15/19 10:51 AM, Per Liden wrote:
>>>> Btw, it's only a bit of a kludge if you're on an old kernel, that
>>>> doesn't have memfd_create() support (kernel < 3.17 and kernel < 4.14
>>>> when using large pages). With memfd_create() support it's pretty much
>>>> transparent, with no need to mount file system, etc.
>>>
>>> I agree, but you still end up with aliases in the TLB. Given that the
>>> L1 TLB is maybe 10-32 items in size, we really shouldn't be using
>>> scarce resources if we can avoid doing so. This is something of a pain
>>> point: Java tends to be memory heavy, with lots of pointer chasing,
>>> and Arm cores tend to be a little smaller than Intel's.
>>
>> Only one of the three heap views (heap mappings) is actively
>> accessed by threads at any given time, so the TLB will be fully
>> utilized with no need to keep aliases around. We're only switching
>> heap views twice per GC cycle (which could be many seconds or
>> minutes apart), so the effect multi-mapping has on the TLB is
>> negligible.
> 
> Thank you, good point. So the only real effect of the multi-mapping
> will be some small additional use of kernel resources and a reduction
> in address space.

Yes, that's correct.

The main problem we've seen so far is more of an educational challenge. 
People often use tools like 'top' and 'ps' to see the %MEM or RSS of the 
process. Unfortunately, RSS is a pretty meaningless number when a 
process has shared mappings (the ZGC heap is a shared mapping). The RSS 
becomes inflated and can confuse users about the actual process size. 
Fortunately, Linux also reports PSS, which is the the more correct and 
non-inflated version of RSS, that people should look at. Tools like 
'smem', 'ps_mem', 'procrank', etc report this (instead of RSS).

> 
> So, I think it's perhaps not so important to use the AArch64 tag bits
> for practical reasons, but I think it's still worth a try,
> 
I completely agree.

/Per