RFC: Dynamic segment table allocation

David Gibson david at gibson.dropbear.id.au
Fri Jul 2 12:02:16 EST 2004


On Thu, Jul 01, 2004 at 07:37:13PM +1000, Anton Blanchard wrote:
>
> Hi,
>
> > Can anyone see a problem with the patch below?  If not, I plan to push
> > it to Andrew in the next few days.  Boots on a 4-way Power3 (RS/6000
> > 270) and an RS64 iSeries lpar.
> >
> > PPC64 machines before Power4 need a segment table page allocated for
> > each CPU.  Currently these are allocated statically in a big array in
> > head.S for all CPUs.  However, except for the boot CPU, there are no
> > particular constraints on the segment table's location, and the
> > secondary CPUs don't come up until quite late when get_free_pages() is
> > operational.
> >
> > This patch dynamically allocates segment table pages as the secondary
> > CPUs come up.  This reduces the kernel image size by 192k...
>
> I like the idea of removing this bloat. However I think all segment tables
> have to be in the first segment, otherwise the bolted segment miss handler
> could take a miss when storing to the segment table.

Ah... good point.

I can see two ways around that:  allocate the tables from bootmem
sufficiently low, or bolt into each table an STE for itself.  Paulus
says he prefers the former option, so I'll look at doing that.

--
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc64-dev mailing list