From: Alex Ghiti <alex@ghiti.fr>
To: Palmer Dabbelt <palmer@sifive.com>
Cc: mingo@kernel.org, aou@eecs.berkeley.edu, catalin.marinas@arm.com,
ndesaulniers@google.com, aghiti@upmem.com,
Christoph Hellwig <hch@infradead.org>,
atish.patra@wdc.com, linux-riscv@lists.infradead.org,
akpm@linux-foundation.org, mike.kravetz@oracle.com
Subject: Re: [PATCH 3/3] riscv: Adjust mmap base address at a third of task size
Date: Sat, 26 Jan 2019 04:23:22 -0500 [thread overview]
Message-ID: <24d86d8d-e1c4-6221-3f5c-84fdaa56e5b4@ghiti.fr> (raw)
In-Reply-To: <mhng-390e0f09-77a1-4943-99a6-6faba4632383@palmer-si-x1c4>
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,
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2019-01-26 9:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 6:21 [PATCH 0/3] Hugetlbfs support for riscv Alexandre Ghiti
2018-12-10 6:21 ` [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel Alexandre Ghiti
2019-01-11 6:18 ` Paul Walmsley
2019-01-11 13:58 ` Alexandre Ghiti
2019-01-15 16:11 ` Christoph Hellwig
2019-01-15 18:52 ` Alex Ghiti
2018-12-10 6:21 ` [PATCH 2/3] riscv: Fix wrong comment about task size for riscv64 Alexandre Ghiti
2019-01-15 15:58 ` Christoph Hellwig
2019-01-15 18:53 ` Alex Ghiti
2019-02-07 12:52 ` Alexandre Ghiti
2018-12-10 6:21 ` [PATCH 3/3] riscv: Adjust mmap base address at a third of task size Alexandre Ghiti
2019-01-15 16:02 ` Christoph Hellwig
2019-01-15 18:54 ` Alex Ghiti
2019-01-25 19:02 ` Palmer Dabbelt
2019-01-26 9:23 ` Alex Ghiti [this message]
2019-01-27 16:57 ` Alex Ghiti
2019-01-28 11:17 ` Alexandre Ghiti
2019-01-07 17:57 ` [PATCH 0/3] Hugetlbfs support for riscv Alex Ghiti
2019-01-07 21:52 ` Paul Walmsley
2019-01-08 9:26 ` Alexandre Ghiti
2019-01-09 18:26 ` Palmer Dabbelt
2019-01-09 19:23 ` Mike Kravetz
2019-01-09 22:15 ` Palmer Dabbelt
2019-01-10 7:33 ` Alex Ghiti
2019-01-10 8:09 ` Alex Ghiti
2019-01-10 18:28 ` Mike Kravetz
2019-01-12 1:09 ` Alex Ghiti
2019-01-15 16:04 ` Christoph Hellwig
2019-01-15 18:56 ` Alex Ghiti
2019-01-15 19:25 ` Mike Kravetz
2019-01-15 20:52 ` Christoph Hellwig
2019-01-16 13:18 ` Alexandre Ghiti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24d86d8d-e1c4-6221-3f5c-84fdaa56e5b4@ghiti.fr \
--to=alex@ghiti.fr \
--cc=aghiti@upmem.com \
--cc=akpm@linux-foundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=catalin.marinas@arm.com \
--cc=hch@infradead.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).