From: William Lee Irwin III <wli@holomorphy.com>
To: Matt Keenan <tank.en.mate@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Bradley Chapman <kakadu@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: CONFIG_HIGHMEM4G and 1GB RAM
Date: Mon, 30 Apr 2007 15:45:36 -0700 [thread overview]
Message-ID: <20070430224536.GQ19966@holomorphy.com> (raw)
In-Reply-To: <46366B34.3050003@gmail.com>
William Lee Irwin III wrote:
>> The CONFIG_VMSPLIT config options were merged for such cases.
>> It should be able to split on any 4MB-aligned boundary in
>> CONFIG_HIGHMEM4G. CONFIG_VMSPLIT_3G_OPT appears to do something of
>> this sort to use an entire 1GB RAM with minimal user address space
>> reduction.
>> This is an ELF ABI violation but the number of major applications
>> that break is apparently low.
On Mon, Apr 30, 2007 at 11:18:28PM +0100, Matt Keenan wrote:
> wine and some java implementations being two of the big caveats.
Understand that when I say this, I remain one of the more staunch
critics of the ABI-violating aspect of the CONFIG_VMSPLIT options.
I would be more in favor of reorganizing the kernel virtual address
space for the case of 1GB laptops. The primary reason it now requires
highmem is that otherwise vmallocspace would alias ZONE_NORMAL, which
is not handled.
The way to handle the aliasing is simple except for the case of vmap();
simply allocate the backing pages for vmalloc() from the virtual
address range aliasing it. IOW, implement vmalloc() as __get_free_pages(),
save for supporting cases beyond power-of-two alignment. vmap() must
carry out a similar reservation to obtain a virtually contiguous range
of memory; however, it must not use the underlying pages. Instead, it
must map the physical pages specified by the caller in the range of
virtual address space reserved in tandem with the physically contiguous
allocation. The physical pages underlying the virtual mapping window,
without a way to window into them as per CONFIG_HIGHMEM, merely stay
reserved until the virtual mapping established by vmap() that clashes
with their static virtual mapping is undone.
In such a manner the static virtualspace reservation for vmallocspace
can be eliminated, and the case of 1GB laptops handled efficiently with
neither highmem nor ABI violations.
If this sounds invasive or difficult, that's because it probably is.
Taking this idea seriously is indicative of the gravity I consider
the issues of laptop/desktop users to have.
-- wli
next prev parent reply other threads:[~2007-04-30 22:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-28 20:26 CONFIG_HIGHMEM4G and 1GB RAM Bradley Chapman
2007-04-30 7:17 ` Andrew Morton
2007-04-30 7:40 ` William Lee Irwin III
2007-04-30 22:18 ` Matt Keenan
2007-04-30 22:45 ` William Lee Irwin III [this message]
2007-05-12 11:08 ` Alejandro Riveira Fernández
-- strict thread matches above, loose matches on Subject: below --
2007-05-01 5:06 Al Boldi
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=20070430224536.GQ19966@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@linux-foundation.org \
--cc=kakadu@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tank.en.mate@gmail.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