2GB address space limit on 32-bit PowerPC Macintosh

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue May 17 10:54:47 EST 2005


> Who cares?  We have the ability to support the memory map flexibility
> for everyone.  If you need it, use it, and fix it if necessary.  There 
> are
> too many other things that need attention.  Again, you are taking one
> of the features we added for embedded boards a long time ago, and
> demanding everyone support it.

Gack ? None of this was 'added for embedded boards'. The initial 2G/2G
split was Cort's decision afaik for the PReP port, and it was PReP and
pmac that introduced the use of BATs for IO mappings, which then got
turned into io_block_mapping() for clarity. Those platorms predate by
far any embedded involvement in the ppc kernel.

>   That's not necessary.   If you want
> to use this feature on a PMac, then use it, but please don't demand
> everyone else do so.  We didn't do that when the feature was added.

It's more than a "feature", it's the way it should have been done in the
first place on 6xx/7xx/7xxx CPUs and wasn't done because of a cheap hack
for IO mapping. I have no problem with other CPU family maintainers
deciding to restrict TASK_SIZE for the sake of saving a couple of
instructions (on 4xx, it's really replacing andis.;beq with
rlwinm;cmpl;bne or something like that, so one instruction, to support
any TASK_SIZE).

> > The whole io_block_mapping() was a bad idea in the first place.
> 
> All of the ideas in 2.6 are going to look like bad ideas in the future 
> :-)

Hrm... If you say so ...

> It's what worked and was necessary given the lack of any other
> APIs at the time. 

ioremap and variants was available at this time and has always been.

>  We are working on removing these in the embedded
> boards, and it has to be done on the PMac as well if you want to
> take advantage of something other than a 2G task space.

Well, you know what ? I've removed them from pmac a long time ago :) And
you know what also ? what you just stated above is _exactly_ what this
thread is all about ... so what are you complaining about ? :)

> As time permits, I will make whatever changes to the board ports
> I'm aware of so they will accommodate a 3G task space, or fix up
> the configuration files so the default is 2G.  At some point, we can
> make it the configuration default.

Good, I'm not asking for anything else here.

Ben.





More information about the Linuxppc-dev mailing list