From: "'David Gibson'" <david@gibson.dropbear.id.au>
To: Ray Bryant <raybry@sgi.com>
Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com>,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
lse-tech@lists.sourceforge.net,
"'Andy Whitcroft'" <apw@shadowen.org>,
"'Andrew Morton'" <akpm@osdl.org>
Subject: Re: hugetlb demand paging patch part [2/3]
Date: Sat, 17 Apr 2004 22:05:40 +1000 [thread overview]
Message-ID: <20040417120540.GC32444@zax> (raw)
In-Reply-To: <40802E69.7040506@sgi.com>
On Fri, Apr 16, 2004 at 02:05:13PM -0500, Ray Bryant wrote:
> David,
>
> Is there a big user demand for copy-on-write support for hugetlb pages?
> I can understand the rationale for making hugetlb pages behave more like
> user pages, and fixing the problem that hugetlb pages are shared across
> fork via MAP_SHARE semantics regardless of whether the user requests
> MAP_PRIVATE or not, but it just doesn't strike me as something that anyone
> who uses hugetlb pages would actually want.
My main interest in it is as a prerequisite for various methods of
"automatically" using hugepages for programs where it is difficult to
manually code them to use hugetlbfs. In particular, think HPC
monsters written in FORTRAN. e.g. automatically putting suitable
aligned anonymous mmap()s in hugepages under some circumstances (I
can't say I like that idea much), using an LD_PRELOAD to put
malloc()ated memory into hugepages, or using a hacked ELF loader to
put the BSS section (again, think FORTRAN) into hugepages (actually
easier and less ugly than it sounds).
In any of these cases having the memory have different semantics
(MAP_SHARED) to normal anonymous memory would clearly be a Bad Thing.
> Of course, YRMV (your requirements may vary). :-)
>
> 'David Gibson' wrote:
> >
> >Well, I'm attempting to understand the hugepage code across all the
> >archs, so that I can try to implement copy-on-write with a minimum of
> >arch specific gunk. Simplifying and consolidating the existing code
> >across archs would be a helpful first step, if possible.
--
David Gibson | For every complex problem there is a
david AT gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
next prev parent reply other threads:[~2004-04-17 12:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-13 23:22 hugetlb demand paging patch part [2/3] Chen, Kenneth W
2004-04-15 7:17 ` David Gibson
2004-04-15 17:27 ` Chen, Kenneth W
2004-04-16 2:34 ` 'David Gibson'
2004-04-16 2:58 ` Chen, Kenneth W
2004-04-16 3:27 ` 'David Gibson'
2004-04-16 4:13 ` Chen, Kenneth W
2004-04-16 4:49 ` 'David Gibson'
2004-04-16 5:56 ` Chen, Kenneth W
2004-04-16 6:15 ` 'David Gibson'
2004-04-16 19:05 ` Ray Bryant
2004-04-17 12:05 ` 'David Gibson' [this message]
2004-04-18 17:36 ` [Lse-tech] " Ray Bryant
2004-04-19 0:47 ` 'David Gibson'
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=20040417120540.GC32444@zax \
--to=david@gibson.dropbear.id.au \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=kenneth.w.chen@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox