mips32 kernel memory mapping

mips32 kernel memory mapping

[Srinivas Kommu]

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. 
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.

Since the user space has a 2 Gig address space, it should be able to access 
it, right? Does the kernel allocate from the whole 1 Gig when the process 
issues a malloc()?

thanks!
Srini

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: mips32 kernel memory mapping

[Maciej W. Rozycki]

On Fri, 23 Jul 2004, Srinivas Kommu 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?

> 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.

  Maciej

Re: mips32 kernel memory mapping

[Ralf Baechle]

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

Re: mips32 kernel memory mapping

[Geert Uytterhoeven]

On Fri, 23 Jul 2004, Ralf Baechle wrote:
> 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!

Perhaps you want to start using virtually mapped zones, like m68k?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: mips32 kernel memory mapping

[Ralf Baechle]

On Fri, Jul 23, 2004 at 10:34:35PM +0200, Geert Uytterhoeven wrote:

> On Fri, 23 Jul 2004, Ralf Baechle wrote:
> > 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!
> 
> Perhaps you want to start using virtually mapped zones, like m68k?

We could do that, yes.  In the cases that would gain most such as the
BCM1250 it'd not be possible though - there simply is not enough virtual
address space left in KSEG2/3.

  Ralf

Re: mips32 kernel memory mapping

[Maciej W. Rozycki]

On Fri, 23 Jul 2004, Ralf Baechle 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.

 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.

> 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.

  Maciej

Re: mips32 kernel memory mapping

[Ralf Baechle]

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

Re: mips32 kernel memory mapping

[Maciej W. Rozycki]

On Fri, 20 Aug 2004, Ralf Baechle wrote:

> 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.

 But large memory holes are not necessarily nice anyway.

  Maciej