From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/2] arm64: fix the bugs found in the hugetlb test
Date: Tue, 8 Nov 2016 16:36:43 +0000 [thread overview]
Message-ID: <20161108163642.GE20591@arm.com> (raw)
In-Reply-To: <20161108140909.GF29087@e104818-lin.cambridge.arm.com>
On Tue, Nov 08, 2016 at 02:09:09PM +0000, Catalin Marinas wrote:
> On Tue, Nov 08, 2016 at 01:44:37PM +0800, Huang Shijie wrote:
> > (3) The test result in the Softiron and Juno-r1 boards:
> >
> > This detail test result shows below (both the "make func" & "make stress"):
> >
> > 4KB granule:
> >
> > 1.1) PTE + Contiguous bit : 4K x 16 = 64K (per huge page size)
> > Test result : PASS
> >
> > 1.2) PMD : 2M x 1 = 2M (per huge page size)
> > Test result : PASS
> >
> > 1.3) PMD + Contiguous bit : 2M x 16 = 32M (per huge page size)
> > Test result : PASS
> >
> > 64KB granule:
> >
> > 3.1) PTE + Contiguous bit : 64K x 32 = 2M (per huge page size)
> > Test result : PASS
> >
> > 3.2) PMD + Contiguous bit : 512M x 32 = 16G (per huge page size)
> > Test result : no hardware to support this test
>
> Don't we have support for single (non-contiguous) PMD huge page with 64K
> pages (512M per huge page)? I gave it a try and it seems to work (though
> without your patches applied ;)).
>
> > Huang Shijie (2):
> > arm64: hugetlb: remove the wrong pmd check in find_num_contig()
> > arm64: hugetlb: fix the wrong address for several functions
>
> For these patches:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
> I'm not sure whether Will plans to push them into 4.9. AFAICT, the
> contiguous huge pages never worked properly, so we may not count it as a
> regression but a new feature. If Will doesn't take them, I'll queue the
> patches for 4.10.
Right, given that it's never worked and the failure only seems to crop up
in synthetic testing, I think you can queue these for 4.10.
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Huang Shijie <shijie.huang@arm.com>,
dwoods@mellanox.com, steve.capper@arm.com,
linux-kernel@vger.kernel.org, kaly.xin@arm.com,
akpm@linux-foundation.org, nd@arm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/2] arm64: fix the bugs found in the hugetlb test
Date: Tue, 8 Nov 2016 16:36:43 +0000 [thread overview]
Message-ID: <20161108163642.GE20591@arm.com> (raw)
In-Reply-To: <20161108140909.GF29087@e104818-lin.cambridge.arm.com>
On Tue, Nov 08, 2016 at 02:09:09PM +0000, Catalin Marinas wrote:
> On Tue, Nov 08, 2016 at 01:44:37PM +0800, Huang Shijie wrote:
> > (3) The test result in the Softiron and Juno-r1 boards:
> >
> > This detail test result shows below (both the "make func" & "make stress"):
> >
> > 4KB granule:
> >
> > 1.1) PTE + Contiguous bit : 4K x 16 = 64K (per huge page size)
> > Test result : PASS
> >
> > 1.2) PMD : 2M x 1 = 2M (per huge page size)
> > Test result : PASS
> >
> > 1.3) PMD + Contiguous bit : 2M x 16 = 32M (per huge page size)
> > Test result : PASS
> >
> > 64KB granule:
> >
> > 3.1) PTE + Contiguous bit : 64K x 32 = 2M (per huge page size)
> > Test result : PASS
> >
> > 3.2) PMD + Contiguous bit : 512M x 32 = 16G (per huge page size)
> > Test result : no hardware to support this test
>
> Don't we have support for single (non-contiguous) PMD huge page with 64K
> pages (512M per huge page)? I gave it a try and it seems to work (though
> without your patches applied ;)).
>
> > Huang Shijie (2):
> > arm64: hugetlb: remove the wrong pmd check in find_num_contig()
> > arm64: hugetlb: fix the wrong address for several functions
>
> For these patches:
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
> I'm not sure whether Will plans to push them into 4.9. AFAICT, the
> contiguous huge pages never worked properly, so we may not count it as a
> regression but a new feature. If Will doesn't take them, I'll queue the
> patches for 4.10.
Right, given that it's never worked and the failure only seems to crop up
in synthetic testing, I think you can queue these for 4.10.
Will
next prev parent reply other threads:[~2016-11-08 16:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-08 5:44 [PATCH v2 0/2] arm64: fix the bugs found in the hugetlb test Huang Shijie
2016-11-08 5:44 ` Huang Shijie
2016-11-08 5:44 ` [PATCH v2 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig() Huang Shijie
2016-11-08 5:44 ` Huang Shijie
2016-11-08 5:44 ` [PATCH v2 2/2] arm64: hugetlb: fix the wrong address for several functions Huang Shijie
2016-11-08 5:44 ` Huang Shijie
2016-11-08 14:09 ` [PATCH v2 0/2] arm64: fix the bugs found in the hugetlb test Catalin Marinas
2016-11-08 14:09 ` Catalin Marinas
2016-11-08 16:36 ` Will Deacon [this message]
2016-11-08 16:36 ` Will Deacon
2016-11-09 1:42 ` Huang Shijie
2016-11-09 1:42 ` Huang Shijie
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=20161108163642.GE20591@arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.