From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Srinivas Kommu <kommu@hotmail.com>, linux-mips@linux-mips.org
Subject: Re: mips32 kernel memory mapping
Date: Fri, 23 Jul 2004 22:24:39 +0200 [thread overview]
Message-ID: <20040723202439.GA3711@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.58L.0407231348580.5644@blysk.ds.pg.gda.pl>
On Fri, Jul 23, 2004 at 01:51:34PM +0200, Maciej W. Rozycki wrote:
> > Can a 32-bit mips kernel access beyond KSEG0 contiguously? I have a Sibyte
> > 1250 with 1 Gig RAM, but only 256 MB is located at phyical 0x0. The rest is
> > all located at 0x8000_0000. Does that mean the kernel can access only 256
> > meg contiguously? Do I need to enabled CONFIG_HIGHMEM to even reach the
> > remaining RAM? It appears Highmem gives me only a 4 meg window at a time.
>
> The BCM1250A is a 64-bit processor. What's the problem with using 64-bit
> Linux avoiding the hassle altogether?
There is a general perception among Linux users that 64-bit is new an
not really needed which in part I blame on the bs Intel is spreading to
hide the fact that for a long time they simply had no 64-bit roadmap at
all.
> > Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2
> > seems to be unused from what I read.
>
> KSEG2 is used for modules.
There are still improvments to be made for BCM1250 support. Somebody
thought scattering the first 1GB of memory through the lowest 4GB of
physical address space like a three year old his toys over the floor
was a good thing ... The resulting holes in the memory map are wasting
significant amounts of memory for unused memory; the worst case number
that is reached for 64-bit kernel on a system with > 1GB of RAM is 96MB!
> > Can't I set up a page mapping into KSEG2 for the rest of the memory? KSEG2
> > seems to be unused from what I read.
>
> KSEG2 is used for modules.
Right. A part of KSEG2 could be used for mapping more low-memory but
that's only really an interesting option for 32-bit processors and would
only raise the theoretical limit from 512MB (256 on BCM1250) to somewhat
less than 1.5GB (BCM1250: 1.25GB) at the cost of address space for
vmalloc & ioremap. It's a pretty pointless exercise when there are
still terabytes of unmapped 64-bit address space available.
Ralf
next prev parent reply other threads:[~2004-07-23 20:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 7:49 mips32 kernel memory mapping Srinivas Kommu
2004-07-23 11:51 ` Maciej W. Rozycki
2004-07-23 20:24 ` Ralf Baechle [this message]
2004-07-23 20:34 ` Geert Uytterhoeven
2004-07-24 0:32 ` Ralf Baechle
2004-07-26 11:23 ` Maciej W. Rozycki
2004-08-20 8:18 ` Ralf Baechle
2004-08-23 12:56 ` Maciej W. Rozycki
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=20040723202439.GA3711@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=kommu@hotmail.com \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.