Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size

Alex Ghiti
2019-01-27T16:58:35Z

On 1/26/19 4:23 AM, Alex Ghiti wrote:
> On 1/25/19 2:02 PM, Palmer Dabbelt wrote:
>> On Tue, 15 Jan 2019 08:02:06 PST (-0800), Christoph Hellwig wrote:
>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>> This ratio is the most used among all other architectures and make
>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>> hugepages whose addresses, without this patch, reach the end of
>>>> the process user address space.
>>>
>>> This does indeed look common, so this looks sensible to me and might
>>> be worth picking up ASAP even without the hugetlb support:
>>>
>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>
>> Makes sense to me.  I'll take it in to the next PR.
>>
>>> I wonder if we should provide this value as a defualt
>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>
>> Looks like arm64 divides by 4 instead of 3.  It appears to have been
>> that way since the start:
>>
>>    commit 4f04d8f00545110a0e525ae2fb62ab38cb417236
>>    Author: Catalin Marinas <catalin.marinas@arm.com>
>>    Date:   Mon Mar 5 11:49:27 2012 +0000
>>           arm64: MMU definitions
>>        ...
>>
>> so maybe that's the right answer?
>
> Maybe, I can't find explanations regarding this arbitrary value.
>
>>
>> On Tue, 15 Jan 2019 10:54:27 PST (-0800), alex@ghiti.fr wrote:
>>> On 1/15/19 4:02 PM, Christoph Hellwig wrote:
>>>> On Mon, Dec 10, 2018 at 06:21:46AM +0000, Alexandre Ghiti wrote:
>>>>> This ratio is the most used among all other architectures and make
>>>>> icache_hygiene libhugetlbfs test pass: this test mmap lots of
>>>>> hugepages whose addresses, without this patch, reach the end of
>>>>> the process user address space.
>>>> This does indeed look common, so this looks sensible to me and might
>>>> be worth picking up ASAP even without the hugetlb support:
>>>>
>>>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>>>>
>>>> I wonder if we should provide this value as a defualt
>>>> TASK_UNMAPPED_BASE if the architecture doesn't provide one.
>>>
>>> Thanks for your review.
>>> I think you're right regarding having a default version of
>>> TASK_UNMAPPED_BASE,
>>> I will propose something.
>>
>> Sounds good to me.  I don't see anything, so I'm still going to take
>> the patch -- we can always drop the redundant definition later.
>
> I did not propose anything yet, I will take the time to find something
> more consistent.
>
> Thanks Palmer,
>
>

Hi Palmer,

I have just sent another patch regarding this issue, I think both are
needed, I don't know
how you want me to proceed, should I merge them, should I rebase this
one on top of the new
one (or the contrary)...

Thanks,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv