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

[Alexandre Ghiti <alex@ghiti.fr>]

On 01/27/2019 05:57 PM, Alex Ghiti wrote:
> 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 

I should have thought more: I will send another version
of my top-down patch rebased against this one, because this patch
is required.

Indeed, there are 2 mmap allocation modes:

- bottom-up which starts allocation using TASK_UNMAPPED_BASE as
   base address,
- top-down which can be used only if the stack size has a limit and
   current personality does not have ADDR_COMPAT_LAYOUT set.

So, in any case, we need to provide the bottom up allocation scheme
and then this patch is required.

Sorry for the noise,

Alex

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


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