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, 20 Aug 2004 10:18:32 +0200 [thread overview]
Message-ID: <20040820081832.GD15543@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.58L.0407261258010.3873@blysk.ds.pg.gda.pl>
On Mon, Jul 26, 2004 at 01:23:41PM +0200, Maciej W. Rozycki wrote:
> > 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.
>
> Huh? How's Intel's policy related to 64-bit Linux? Especially for other
> processors, like MIPS.
Their wrong claims that only server machines need 64-bit.
> Linux has supported 64-bit operation since ~1995 and around 1998 when I
> had an opportunity to use it on DEC Alpha, it (2.0.x) was already stable
> enough for regular use. That is the generic core and the Alpha bits, of
> course -- the maturity of other processor support may vary, but for MIPS
> it's not worse than the 32-bit support.
At least after I fixed kernel mode page tables last week. The 4MB limit
we had before that was just ridiculous.
> > 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!
>
> Well, there are some resons given in the manual. Anyway, memory seems to
> be remappable to 0x100000000 in the DRAM controller. Still we probably
> have to keep low 256MB mapped and registered within Linux at 0 for bounce
> buffers for broken PCI hardware ("hidden" mapping for exception handlers
> and kernel segments would be easier).
>
> With only 256MB installed in my system it would be tough for me to code
> anything interesting, though. Perhaps another time.
I have 1GB and that's where 32-bit kernels are beginning to look really
like a bad idea on MIPS. Fortunately on the BCM1250 and all the other
64-bit processors there is an easy way out. Better even, some of the
embedded application performance numbers suggest significant performance
gains for 64-bit processing contrary to conventional wisdom about 64-bit
computing.
Ralf
next prev parent reply other threads:[~2004-08-20 8:18 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
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 [this message]
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=20040820081832.GD15543@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.