vm changes from linux-2.6.14 to linux-2.6.15

Mark Fortescue mark at mtfhpc.demon.co.uk
Tue May 1 08:33:13 EST 2007


Hi David,

Is this just sun4c or does it affect other sparc32 architectures.

Regards
 	Mark Fortescue.

On Mon, 30 Apr 2007, David Miller wrote:

> From: Andrew Morton <akpm at linux-foundation.org>
> Date: Mon, 30 Apr 2007 14:54:14 -0700
>
>> On Mon, 30 Apr 2007 22:36:27 +0100 (BST)
>> Mark Fortescue <mark at 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.
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



More information about the Linuxppc-dev mailing list