From: William Lee Irwin III <wli@holomorphy.com>
To: Roberto Fichera <kernel@tekno-soft.it>
Cc: Michael Tokarev <mjt@tls.msk.ru>, linux-kernel@vger.kernel.org
Subject: Re: How to use memory over 4GB
Date: Mon, 16 May 2005 08:54:22 -0700 [thread overview]
Message-ID: <20050516155422.GM9304@holomorphy.com> (raw)
In-Reply-To: <6.2.1.2.2.20050516174053.07185270@mail.tekno-soft.it>
At 17.10 16/05/2005, William Lee Irwin III wrote:
>> This approach has already been used in production by various major
>> applications and is even obsolete, now replaced by remap_file_pages()
>> (in Linux), where it and its counterparts in other operating systems
>> have been in use in production by various major applications for some time.
>> remap_file_pages() allows virtual pages in an mmap() area to correspond
>> in an unrestricted fashion to the pages of the underlying file, and to
>> alter this correspondence at will.
>> In particular, Oracle's "vlm" option does this.
On Mon, May 16, 2005 at 05:47:31PM +0200, Roberto Fichera wrote:
> So, you are suggesting to create one big tmpfs area, 6GB for example, than
> mmap() it to the user process and use the remap_file_pages() for all
> the objects I want make "addressable" on the user process taking care
> the return value of -1 which implies to munmap() something to free vm space?
I don't have any specific suggestion regarding layout or usage patterns
besides pointing to remap_file_pages() being significantly lighter-weight
than mmap() for the purposes of virtual windowing. The other aspects of
all this (and even the use of remap_file_pages() at all) are, of course,
at your own discretion. It is, however, notable that Oracle has had some
success with a tactic similar to what you describe, where few objects are
used and the application instead manages space within the objects
dedicated to various purposes.
In general, I'd recommend experimenting with different strategies to see
which works best for you. This is all rather vague, and the mechanics of
getting all this working with your application are sure to have enough
alternative implementations to merit some decision-making and the like.
-- wli
next prev parent reply other threads:[~2005-05-16 15:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-16 12:42 How to use memory over 4GB Roberto Fichera
2005-05-16 12:56 ` Michael Tokarev
2005-05-16 13:16 ` Roberto Fichera
2005-05-16 15:10 ` William Lee Irwin III
2005-05-16 15:47 ` Roberto Fichera
2005-05-16 15:54 ` William Lee Irwin III [this message]
2005-05-16 16:37 ` Roberto Fichera
2005-05-16 19:14 ` Bill Davidsen
2005-05-16 12:57 ` Eric Dumazet
2005-05-16 13:18 ` Roberto Fichera
2005-05-16 14:17 ` Eric Dumazet
2005-05-16 14:50 ` Roberto Fichera
2005-05-16 21:34 ` Nix
2005-05-17 7:15 ` Roberto Fichera
2005-05-16 15:22 ` William Lee Irwin III
-- strict thread matches above, loose matches on Subject: below --
2005-05-16 12:55 li nux
2005-05-16 13:06 ` Roberto Fichera
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=20050516155422.GM9304@holomorphy.com \
--to=wli@holomorphy.com \
--cc=kernel@tekno-soft.it \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
/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