From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Arjan van de Ven <arjan@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: How to alloc highmem page below 4GB on i386?
Date: Fri, 4 Jul 2008 22:23:23 +0200 [thread overview]
Message-ID: <20080704222323.68afbe88@mjolnir.drzeus.cx> (raw)
In-Reply-To: <20080704111224.68266afc@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Fri, 4 Jul 2008 11:12:24 -0700
Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 4 Jul 2008 19:58:00 +0200
> Pierre Ossman <drzeus-list@drzeus.cx> wrote:
>
> > On Mon, 30 Jun 2008 20:03:23 +0200
> > Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> >
> > > Simple question. How do I allocate a page from highmem, that's still
> > > within 32 bits? x86_64 has the DMA32 zone, but i386 has just
> > > HIGHMEM. As most devices can't DMA above 32 bit, I have 3 GB of
> > > memory that's not getting decent usage (or results in needless
> > > bouncing). What to do?
> > >
> > > I tried just enabling CONFIG_DMA32 for i386, but there is some guard
> > > against too many memory zones. I'm assuming this is there for a good
> > > reason?
> > >
> >
> > Anyone?
> >
>
> well... the assumption sort of is that all high-perf devices are 64 bit
> capable. For the rest... well you get what you get. There's IOMMU's in
> modern systems from Intel (and soon AMD) that help you avoid the bounce
> if you really care.
I was under the impression that the PCI bus was utterly incapable of
any larger address than 32 bits? But perhaps you only consider PCIE
stuff high-perf. :)
>
> The second assumption sort of is that you don't have 'too much' above
> 4Gb; once you're over 16Gb or so people assume you will run the 64 bit
> kernel instead...
Unfortunately some proprietary crud keeps migration somewhat annoying.
And in my case it's a 4 GB system, where 1 GB gets mapped up to make
room for devices, so it's not that uncommon.
The strange thing is that I keep getting pages from > 4GB all the time,
even on a loaded system. I would have expected mostly getting pages
below that limit as that's where most of the memory is. Do you have any
insight into which areas tend to fill up first?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-07-04 20:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 18:03 Pierre Ossman
2008-07-04 17:58 ` Pierre Ossman
2008-07-04 18:12 ` Arjan van de Ven
2008-07-04 20:23 ` Pierre Ossman [this message]
2008-07-04 20:37 ` Arjan van de Ven
2008-07-04 22:02 ` Pierre Ossman
2008-07-04 22:24 ` Arjan van de Ven
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=20080704222323.68afbe88@mjolnir.drzeus.cx \
--to=drzeus-list@drzeus.cx \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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