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