From: Andrea Arcangeli <andrea@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>,
Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: 2.4.22pre6aa1
Date: Sat, 19 Jul 2003 00:53:28 +0200 [thread overview]
Message-ID: <20030718225328.GQ3928@dualathlon.random> (raw)
In-Reply-To: <20030718224824.GP15452@holomorphy.com>
On Fri, Jul 18, 2003 at 03:48:24PM -0700, William Lee Irwin III wrote:
> On Sat, Jul 19, 2003 at 12:27:50AM +0200, Andrea Arcangeli wrote:
> > bigpages= is a documented API that has to be used in production, so I
> > can easily add the hugetlbfs API but I guess I've to keep this one
> > anyways. I also would need to verify the performance of hugetlbfs before
> > suggesting migrating to it, for example I don't want
> > preallocation/prefaulting (IIRC hugetlbfs preallocates everything). I
> > also like the single huge array of page pointers, that is very hardwired
> > but optimal for those workloads.
>
> Most of the complaints I've gotten are about lack of support for mixed
> PSE and non-PSE mappings, not preallocation or performance (generally
> its usage doesn't involve creation/destruction cycle performance
> requirements, and most of the time they intend to use 100% of the memory).
>
> It's basically too stupid and operating on too small a data set to
> screw up performance-wise apart from creation/destruction, which is not
> intended to be performant (and will never be; it blits oversized areas).
>
> I wouldn't mind hearing of what you believe is missing, so long as it's
> within the constraints of what's mergeable. =(
I tend to think the creation/destruction will be the most noticeable
performance difference in practice. allocating 42G in a single block
will take a bit of time ;). I'm not necessairly worse or unacceptable,
but it's different. And I feel I've to retain the bigpages= API (as an
API not as in implementation) anyways. Furthmore I'm unsure if hugtlbfs
is relaxed like the shm-largpeage patch is, I mean, it should be
possible to mmap the stuff with 4k granularty too, or stuff could break
due that change of API too.
Andrea
next prev parent reply other threads:[~2003-07-18 22:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-17 10:28 2.4.22pre6aa1 Andrea Arcangeli
2003-07-17 10:42 ` 2.4.22pre6aa1 ooyama eiichi
2003-07-17 10:52 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-17 10:53 ` 2.4.22pre6aa1 ooyama eiichi
2003-07-17 15:42 ` 2.4.22pre6aa1 Dave Jones
2003-07-17 20:31 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-17 22:13 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-17 22:26 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-17 22:27 ` 2.4.22pre6aa1 Mike Fedyk
2003-07-17 22:32 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-17 22:30 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-17 22:50 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-18 0:30 ` 2.4.22pre6aa1 Chris Mason
2003-07-22 12:28 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-22 14:04 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-18 5:47 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-22 13:34 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-22 13:59 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-24 12:27 ` 2.4.22pre6aa1 Marc-Christian Petersen
2003-07-24 14:14 ` 2.4.22pre6aa1 Chris Mason
2003-07-18 18:18 ` 2.4.22pre6aa1 Christoph Hellwig
2003-07-18 22:27 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-18 22:48 ` 2.4.22pre6aa1 William Lee Irwin III
2003-07-18 22:53 ` Andrea Arcangeli [this message]
2003-07-18 23:04 ` 2.4.22pre6aa1 William Lee Irwin III
2003-07-18 23:12 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-18 23:53 ` 2.4.22pre6aa1 William Lee Irwin III
2003-07-19 0:04 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-23 11:21 2.4.22pre6aa1 Sergey S. Kostyliov
2003-07-25 5:28 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-07-25 11:10 ` 2.4.22pre6aa1 Sergey S. Kostyliov
2003-07-25 19:02 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-08-03 17:12 ` 2.4.22pre6aa1 Sergey S. Kostyliov
2003-08-16 11:56 ` 2.4.22pre6aa1 Andrea Arcangeli
2003-08-16 13:54 ` 2.4.22pre6aa1 Hugh Dickins
2003-08-16 14:00 ` 2.4.22pre6aa1 Hugh Dickins
2003-08-16 14:50 ` 2.4.22pre6aa1 Sergey S. Kostyliov
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=20030718225328.GQ3928@dualathlon.random \
--to=andrea@suse.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.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).