From: Ray Fucillo <Ray.Fucillo@intersystems.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Ray Fucillo <Ray.Fucillo@intersystems.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: scalability regressions related to hugetlb_fault() changes
Date: Fri, 25 Mar 2022 13:33:03 +0000 [thread overview]
Message-ID: <CD631DCE-22C1-41FF-A55D-CCB393230851@intersystems.com> (raw)
In-Reply-To: <1883d31a-639e-8717-39b1-426628cb0d56@oracle.com>
> On Mar 25, 2022, at 12:40 AM, Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> I will continue to look at this. A quick check of the fork code shows the
> semaphore held in read mode for the duration of the page table copy.
Thank you for looking into it.
As a side note about fork() for context, and not to distract from the
regression at hand... There's some history here where we ran into problems
circa 2005 where fork time went linear with the size of shared memory, and
that was resolved by letting the pages fault in the child. This was when
hugetlb was pretty new (and not used by us) and I see now that the fix
explicitly excluded hugetlb. Anyway, we now mostly use vfork(), only fork()
in some special cases, and improving just fork wouldn't fix the scalability
regression for us. But, it does sound like fork() time might be getting
large again now that everyone is using very large shared segments with
hugetlb, but generally haven't switched to 1GB pages. That old thread is:
https://lkml.org/lkml/2005/8/24/190
next prev parent reply other threads:[~2022-03-25 13:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 20:12 scalability regressions related to hugetlb_fault() changes Ray Fucillo
2022-03-24 21:55 ` Randy Dunlap
2022-03-24 22:41 ` Mike Kravetz
2022-03-25 0:02 ` Ray Fucillo
2022-03-25 4:40 ` Mike Kravetz
2022-03-25 13:33 ` Ray Fucillo [this message]
2022-03-28 18:30 ` Mike Kravetz
2022-03-30 12:22 ` Thorsten Leemhuis
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=CD631DCE-22C1-41FF-A55D-CCB393230851@intersystems.com \
--to=ray.fucillo@intersystems.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.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).