| Message ID | 20181210062146.24951-4-aghiti@upmem.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Hugetlbfs support for riscv | expand |
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.
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. Alex > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
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? 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.
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,
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
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
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h index 0531f49af5c3..ce70bceb8872 100644 --- a/arch/riscv/include/asm/processor.h +++ b/arch/riscv/include/asm/processor.h @@ -22,7 +22,7 @@ * This decides where the kernel will search for a free chunk of vm * space during mmap's. */ -#define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE >> 1) +#define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE / 3) #define STACK_TOP TASK_SIZE #define STACK_TOP_MAX STACK_TOP
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. Signed-off-by: Alexandre Ghiti <aghiti@upmem.com> --- arch/riscv/include/asm/processor.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)