Linux speed on sun4c

Linux speed on sun4c

[Aaron Lehmann]

NetBSD/Sparc's FAQ asserts:

    Why is NetBSD so much faster than SparcLinux on sun4c (top) 

        The memory management hardware on sun4c machines (SPARCStation
        1, 1+, 2, IPC, IPX, SLC, ELC and clones) is not handled particularly
        well by Linux. Until Linux reworks their MMU code NetBSD will be very
        much faster on this hardware. 

Was there ever any truth to this statement? It seems to be light on
technical details. Have these purported issues ever been fixed?

I don't want to be scared into running NetBSD on my SparcStation 2 :D.

Re: Linux speed on sun4c

[David S. Miller]

Aaron Lehmann writes:
 > 
 > NetBSD/Sparc's FAQ asserts:
 > 
 >     Why is NetBSD so much faster than SparcLinux on sun4c (top) 
 > 
 >         The memory management hardware on sun4c machines (SPARCStation
 >         1, 1+, 2, IPC, IPX, SLC, ELC and clones) is not handled particularly
 >         well by Linux. Until Linux reworks their MMU code NetBSD will be very
 >         much faster on this hardware. 
 > 
 > Was there ever any truth to this statement? It seems to be light on
 > technical details. Have these purported issues ever been fixed?
 > 
 > I don't want to be scared into running NetBSD on my SparcStation 2 :D.

It's totally true, use *BSD on your sun4c systems if top performance
is your desire. :-)

I know how to fix it but frankly I have no desire to work on
that platform any more.

Later,
David S. Miller
davem@redhat.com

Re: Linux speed on sun4c

[Guenter Millahn]

On Sat, 30 Jun 2001, David S. Miller wrote:

> Aaron Lehmann writes:
>  > NetBSD/Sparc's FAQ asserts:
>  > 
>  >     Why is NetBSD so much faster than SparcLinux on sun4c (top) 
>  > 
>  >         The memory management hardware on sun4c machines (SPARCStation
>  >         1, 1+, 2, IPC, IPX, SLC, ELC and clones) is not handled particularly
>  >         well by Linux. Until Linux reworks their MMU code NetBSD will be very
>  >         much faster on this hardware. 
>  > 
>  > Was there ever any truth to this statement? It seems to be light on
>  > technical details. Have these purported issues ever been fixed?
>  > 
>  > I don't want to be scared into running NetBSD on my SparcStation 2 :D.


What about OpenBSD?  Same as NetBSD?



> It's totally true, use *BSD on your sun4c systems if top performance
> is your desire. :-)
> 
> I know how to fix it but frankly I have no desire to work on
> that platform any more.
> 
> Later,
> David S. Miller
> davem@redhat.com


David, can you publish your idea for a fix? Possibly anybody elese can make
the patch?

Thanks, Guenter

-- 
Dipl.-Ing. Guenter Millahn         Brandenburg University of Technology
Systems, Network & DB Admin        CS Dept / DB & IS Research Group
Voice: +49 (355) 69-2272/2700      P.O. Box: 10 13 44
Fax:   +49 (355) 69-2766           D-03013 Cottbus              GERMANY

"The real world is still far away from be led ad absurdum by the virtual
one."    (Hal Faber, newsreel "What happened, what will be", 08/13/2000)

Re: Linux speed on sun4c

[David S. Miller]

Guenter Millahn writes:
 > David, can you publish your idea for a fix? Possibly anybody elese can make
 > the patch?

Currently under Linux when a constext is recycled because a new
context is needed but all are in use, we basically toss all of
the MMU segments that context owned.

This is bogus because if the contexts are the limited resource
not the MMU segments themselves, we take a lot of false MMU
misses on each context switch for no reason.

The solution is to link the MMU segment software state structures
into the mm_struct.  When an 'mm' reacquires a hw context, if any
MMU segments remain on the mm's list, just pluck them back into
the MMU.

Later,
David S. Miller
davem@redhat.com

Re: Linux speed on sun4c

[Nico Schottelius]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Did anybody wrote a patch for that?

Nico

David S. Miller [Tue, Jul 03, 2001 at 04:07:16PM -0700]:
> 
> Guenter Millahn writes:
>  > David, can you publish your idea for a fix? Possibly anybody elese can make
>  > the patch?
> 
> Currently under Linux when a constext is recycled because a new
> context is needed but all are in use, we basically toss all of
> the MMU segments that context owned.
> 
> This is bogus because if the contexts are the limited resource
> not the MMU segments themselves, we take a lot of false MMU
> misses on each context switch for no reason.
> 
> The solution is to link the MMU segment software state structures
> into the mm_struct.  When an 'mm' reacquires a hw context, if any
> MMU segments remain on the mm's list, just pluck them back into
> the MMU.
> 
> Later,
> David S. Miller
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]