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.
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
[email protected]
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
> [email protected]
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)
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
[email protected]
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
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> 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