From: William Lee Irwin III <wli@holomorphy.com>
To: Ray Bryant <raybry@sgi.com>
Cc: lse-tech@lists.sourceforge.net,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Hugetlbpages in very large memory machines.......
Date: Sat, 13 Mar 2004 03:55:11 +0000 [thread overview]
Message-ID: <20040313035511.GZ655@holomorphy.com> (raw)
In-Reply-To: <40528383.10305@sgi.com>
On Fri, Mar 12, 2004 at 09:44:03PM -0600, Ray Bryant wrote:
> We've run into a scaling problem using hugetlbpages in very large memory
> machines, e. g. machines with 1TB or more of main memory. The problem is
> that hugetlbpage pages are not faulted in, rather they are zeroed and
> mapped in in by hugetlb_prefault() (at least on ia64), which is called in
> response to the user's mmap() request. The net is that all of the hugetlb
> pages end up being allocated and zeroed by a single thread, and if most of
> the machine's memory is allocated to hugetlb pages, and there is 1 TB or
> more of main memory, zeroing and allocating all of those pages can take a
> long time (500 s or more).
> We've looked at allocating and zeroing hugetlbpages at fault time, which
> would at least allow multiple processors to be thrown at the problem.
> Question is, has anyone else been working on
> this problem and might they have prototype code they could share with us?
This actually is largely a question of architecture-dependent code, so
the answer will depend on whether your architecture matches those of the
others who have had a need to arrange this.
Basically, all you really need to do is to check the vma and call either
a hugetlb-specific fault handler or handle_mm_fault() depending on whether
hugetlb is configured. Once you've gotten that far, it's only a question
of implementing the methods to work together properly when driven by
upper layers.
The reason why this wasn't done up-front was that there wasn't a
demonstrable need to do so. The issue you're citing is exactly the kind
of demonstration needed to motivate its inclusion.
-- wli
WARNING: multiple messages have this Message-ID (diff)
From: William Lee Irwin III <wli@holomorphy.com>
To: Ray Bryant <raybry@sgi.com>
Cc: lse-tech@lists.sourceforge.net,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: Hugetlbpages in very large memory machines.......
Date: Fri, 12 Mar 2004 19:55:11 -0800 [thread overview]
Message-ID: <20040313035511.GZ655@holomorphy.com> (raw)
In-Reply-To: <40528383.10305@sgi.com>
On Fri, Mar 12, 2004 at 09:44:03PM -0600, Ray Bryant wrote:
> We've run into a scaling problem using hugetlbpages in very large memory
> machines, e. g. machines with 1TB or more of main memory. The problem is
> that hugetlbpage pages are not faulted in, rather they are zeroed and
> mapped in in by hugetlb_prefault() (at least on ia64), which is called in
> response to the user's mmap() request. The net is that all of the hugetlb
> pages end up being allocated and zeroed by a single thread, and if most of
> the machine's memory is allocated to hugetlb pages, and there is 1 TB or
> more of main memory, zeroing and allocating all of those pages can take a
> long time (500 s or more).
> We've looked at allocating and zeroing hugetlbpages at fault time, which
> would at least allow multiple processors to be thrown at the problem.
> Question is, has anyone else been working on
> this problem and might they have prototype code they could share with us?
This actually is largely a question of architecture-dependent code, so
the answer will depend on whether your architecture matches those of the
others who have had a need to arrange this.
Basically, all you really need to do is to check the vma and call either
a hugetlb-specific fault handler or handle_mm_fault() depending on whether
hugetlb is configured. Once you've gotten that far, it's only a question
of implementing the methods to work together properly when driven by
upper layers.
The reason why this wasn't done up-front was that there wasn't a
demonstrable need to do so. The issue you're citing is exactly the kind
of demonstration needed to motivate its inclusion.
-- wli
next prev parent reply other threads:[~2004-03-13 3:55 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-13 3:44 Hugetlbpages in very large memory machines Ray Bryant
2004-03-13 3:44 ` Ray Bryant
2004-03-13 3:45 ` Ray Bryant
2004-03-13 3:45 ` Ray Bryant
2004-03-13 3:48 ` Andi Kleen
2004-03-13 3:48 ` Andi Kleen
2004-03-13 5:49 ` William Lee Irwin III
2004-03-13 5:49 ` William Lee Irwin III
2004-03-13 16:10 ` [Lse-tech] " Andi Kleen
2004-03-13 16:10 ` Andi Kleen
2004-03-14 0:05 ` William Lee Irwin III
2004-03-14 0:05 ` William Lee Irwin III
2004-03-14 5:22 ` Peter Chubb
2004-03-14 5:22 ` Peter Chubb
2004-03-15 23:31 ` Seth, Rohit
2004-03-15 23:31 ` Seth, Rohit
[not found] ` <844231526.20040313030948@adinet.com.uy>
[not found] ` <20040313061232.GB655@holomorphy.com>
2004-03-13 16:32 ` Re[2]: " Luis Mirabal
2004-03-14 2:45 ` Andrew Morton
2004-03-14 2:45 ` Andrew Morton
2004-03-14 4:06 ` [Lse-tech] " Anton Blanchard
2004-03-14 4:06 ` Anton Blanchard
2004-03-17 19:05 ` [Lse-tech] Re: Hugetlbpages in very large memory Andy Whitcroft
2004-03-17 19:05 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andy Whitcroft
2004-03-18 20:25 ` [Lse-tech] Re: Hugetlbpages in very large memory Andrew Morton
2004-03-18 20:25 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andrew Morton
2004-03-18 21:22 ` [Lse-tech] Re: Hugetlbpages in very large memory Stephen Smalley
2004-03-18 21:22 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Stephen Smalley
2004-03-18 22:21 ` [Lse-tech] Re: Hugetlbpages in very large memory Andy Whitcroft
2004-03-18 22:21 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andy Whitcroft
2004-03-23 17:30 ` [Lse-tech] Re: Hugetlbpages in very large memory Andy Whitcroft
2004-03-23 17:30 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andy Whitcroft
2004-03-24 17:38 ` [Lse-tech] Re: Hugetlbpages in very large memory Andy Whitcroft
2004-03-24 17:38 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andy Whitcroft
2004-03-14 8:38 ` Ray Bryant
2004-03-14 8:38 ` Ray Bryant
2004-03-14 8:48 ` William Lee Irwin III
2004-03-14 8:48 ` William Lee Irwin III
2004-03-14 8:57 ` [Lse-tech] Re: Hugetlbpages in very large memory Andrew Morton
2004-03-14 8:57 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andrew Morton
2004-03-14 9:02 ` [Lse-tech] Re: Hugetlbpages in very large memory Andrew Morton
2004-03-14 9:02 ` [Lse-tech] Re: Hugetlbpages in very large memory machines Andrew Morton
2004-03-14 9:07 ` William Lee Irwin III
2004-03-14 9:07 ` William Lee Irwin III
2004-03-15 6:45 ` Ray Bryant
2004-03-15 6:45 ` Ray Bryant
2004-03-15 23:54 ` William Lee Irwin III
2004-03-15 23:54 ` William Lee Irwin III
2004-03-13 3:55 ` William Lee Irwin III [this message]
2004-03-13 3:55 ` William Lee Irwin III
2004-03-13 4:56 ` Hirokazu Takahashi
2004-03-13 4:56 ` Hirokazu Takahashi
2004-03-16 0:30 ` Nobuhiko Yoshida
2004-03-16 0:30 ` Nobuhiko Yoshida
2004-03-16 1:54 ` Andi Kleen
2004-03-16 1:54 ` Andi Kleen
2004-03-16 2:32 ` Hirokazu Takahashi
2004-03-16 2:32 ` Hirokazu Takahashi
2004-03-16 3:20 ` Hirokazu Takahashi
2004-03-16 3:20 ` Hirokazu Takahashi
2004-03-16 3:15 ` Nobuhiko Yoshida
2004-03-16 3:15 ` Nobuhiko Yoshida
2004-04-01 9:10 ` Nobuhiko Yoshida
2004-04-01 9:10 ` Nobuhiko Yoshida
2004-03-15 15:28 ` jlnance
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=20040313035511.GZ655@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=raybry@sgi.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 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.