On Thu 28-06-18 15:16:46, Cannon Matthews wrote:
> Thanks for the quick turnaround.
>
> Good to know about the how the 2M code path differs, I have been
> trying to trace through some of this and it's easy to get lost between
> which applies to which size.
Yeah, GB hugetlb pages implementation ha
Thanks for the quick turnaround.
Good to know about the how the 2M code path differs, I have been
trying to trace through some of this and it's easy to get lost between
which applies to which size.
Thanks!
On Thu, Jun 28, 2018 at 12:03 PM Michal Hocko wrote:
>
> On Wed 27-06-18 14:44:47, Cannon
On Wed 27-06-18 14:44:47, Cannon Matthews wrote:
> When booting with very large numbers of gigantic (i.e. 1G) pages, the
> operations in the loop of gather_bootmem_prealloc, and specifically
> prep_compound_gigantic_page, takes a very long time, and can cause a
> softlockup if enough pages are requ
On Wed, 27 Jun 2018 16:27:24 -0700 Mike Kravetz wrote:
> My only suggestion would be to remove the mention of 2M pages in the
> commit message. Thanks for adding this.
I have removed that sentence.
> Reviewed-by: Mike Kravetz
Thanks again.
On 06/27/2018 02:44 PM, Cannon Matthews wrote:
> When booting with very large numbers of gigantic (i.e. 1G) pages, the
> operations in the loop of gather_bootmem_prealloc, and specifically
> prep_compound_gigantic_page, takes a very long time, and can cause a
> softlockup if enough pages are reques
When booting with very large numbers of gigantic (i.e. 1G) pages, the
operations in the loop of gather_bootmem_prealloc, and specifically
prep_compound_gigantic_page, takes a very long time, and can cause a
softlockup if enough pages are requested at boot.
For example booting with 3844 1G pages re
6 matches
Mail list logo
