[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <965d3ea8-4dd9-8f66-7ac0-0d6aa7fcadc7@google.com>
Date: Wed, 29 Nov 2023 11:41:52 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Gang Li <ligang.bdlg@...edance.com>
cc: David Hildenbrand <david@...hat.com>, Gang Li <gang.li@...ux.dev>,
Mike Kravetz <mike.kravetz@...cle.com>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/4] hugetlb: parallelize hugetlb page allocation
on boot
On Tue, 28 Nov 2023, Gang Li wrote:
> >
> > > And there, the 65.2s won't be noise because that 12TB system is up by a
> > > snap
> > > of a finger? :)
> > >
> >
> > In this single boot test, total boot time was 373.78s, so 1GB hugetlb
> > allocation is 17.4% of that.
>
> Thank you for sharing these data. Currently, I don't have access to a machine
> of such large capacity, so the benefits in my tests are not as pronounced.
>
> I believe testing on a system of this scale would yield significant benefits.
>
> >
> > Would love to see what the numbers would look like if 1GB pages were
> > supported.
> >
>
> Support for 1GB hugetlb is not yet perfect, so it wasn't included in v1. But
> I'm happy to refine and introduce 1GB hugetlb support in future versions.
>
That would be very appreciated, thank you! I'm happy to test and collect
data for any proposed patch series on 12TB systems booted with a lot of
1GB hugetlb pages on the kernel command line.
Powered by blists - more mailing lists