Re: vm changes from linux-2.6.14 to linux-2.6.15

David Miller
2007-04-30T22:04:07Z

> On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
> Mark Fortescue <mark@mtfhpc.demon.co.uk> wrote:
>
> > Hi all,
> >
> > I have tracked down a failure to successfully load/run the init task on my
> > Sparcstation 1 clone (SS1) and Sparcstation 2 (SS2), sparc32 sun4c
> > systems, to a patch:
> >
> > commit 1a44e149084d772a1bcf4cdbdde8a013a8a1cfde.
> > [PATCH] .text page fault SMP scalability optimization
> >
> > Removing this patch fixes the issue and allows me to use kernels later
> > than v2.5.14. (tested using linux-2.6.20.9).
> >
> > Given the comment provided by the git bisect, backing out this patch will
> > probably have undesirable conseqnences for other platforms (especially
> > powerpc64) so, if an architecture independent solution is not available,
> > some/all of the code in handle_pte_fault() in mm/memory.c will need be to
> > made architecture dependent.
> >
> > I am not sufficiently familear with the how the SS1/SS2 mmu works and how
> > the linux memory management system works to understand why this patch
> > prevents my sun4c SS1/SS2 systems from working.
> >
> > Advice and help on the approch to take and any code changes regarding this
> > issue would be most welcome.
> >
>
> Interesting - thanks for working that out. Let's keep linux-mm on cc please.

You can't elide the update_mmu_cache() call on sun4c because that will
miss some critical TLB setups which are performed there.

The sun4c TLB has two tiers of entries:

1) segment maps, these hold ptes for a range of addresses
2) ptes, mapped into segment maps

update_mmu_cache() on sun4c take care of allocating and setting
up the segment maps, so if you elide the call this never happens
and we fault forever.