From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: XFS appears to cause strange hang with md raid1 on reboot
Date: Wed, 30 Jan 2013 02:54:56 -0600 [thread overview]
Message-ID: <5108DFE0.2060908@hardwarefreak.com> (raw)
In-Reply-To: <22819.192.104.24.222.1359498326.squirrel@secure.skymagik.net>
On 1/29/2013 4:25 PM, Tom wrote:
> For the SGI engineers on this list, I do miss IRIX though... it will
> always have a special place in my heart -- if only that OS and its tools
> could have been open sourced...
Much of the differentiating/unique technology has been. XFS and its
user space tools obviously. Lesser known is that Paul Jackson and
others at SGI contributed the basic NUMA scalability code to Linux
during the Linux Scalability Effort in the early 2000s, based heavily on
IRIX concepts. This included cpumemsets, directly taken from IRIX IIRC,
which evolved into Linux mainline cpusets.
This effort was necessary to get Linux to scale on Altix NUMALink
systems with up to 512 sockets, as well as IBM's Xeon based x440 NUMA
box with up to 16 sockets, HP's cell based Itanium systems w/32 sockets,
and clones of HP's cell design used by the likes of Bull, Unisys, NEC,
and others. This work later turned out to be of great benefit to the
market at large, as the underpinnings were already in place when AMD
launched Opteron, whose 2/4/8 socket platforms use HT NUMA
interconnects. Same for Intel when it finally went NUMA with QuickPath.
This infrastructure also allowed for a relatively easy implementation
of multi-core support on single and multi-socket systems.
AIUI, from articles, not first hand experience, is that what did not
make it into Linux was the tendency of some SGI engineers to write
bloated inefficient code with unnecessarily large data structures. This
occurred because IRIX developers were working on 8-32 CPU systems (or
larger) with 8-32GB (or more) of RAM, and weren't concerned with single
processor performance or memory efficiency, as they had massive
resources available. When the scalability concepts were brought over to
Linux, they were bolted onto the mantra of maximum single processor
performance and small memory footprint, and we got the best of both
worlds, without the previous IRIX overhead.
I recall reading an article from that period which described an early
Linux porting effort to Origin/MIPS. This was a 16-way machine used as
a development mule to get Linux working on NUMALink, ready for
Altix/Itanium. It was described that even before any NUMA scalability
work began, with a large number of operations the stock SMP Linux kernel
was much faster than IRIX on this 16 CPU origin box. "Amazing" is a
description I recall. It had been assumed Linux would be a dog since it
was optimized for small systems. It turns out it worked just as well on
the big ones, due to said small system optimizations.
So in some respects it's probably better that IRIX simply was abandoned,
with some of the best parts making it into Linux.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-01-30 8:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 23:28 XFS appears to cause strange hang with md raid1 on reboot Tom
2013-01-29 0:05 ` Eric Sandeen
2013-01-29 21:47 ` Tom
2013-01-29 21:55 ` Eric Sandeen
2013-01-29 22:25 ` Tom
2013-01-29 22:39 ` Ben Myers
2013-01-30 8:54 ` Stan Hoeppner [this message]
2013-01-29 15:18 ` Ben Myers
2013-01-29 21:13 ` Tom
2013-01-30 3:16 ` Tom
2013-01-30 22:51 ` Ben Myers
2013-01-30 23:46 ` Dave Chinner
2013-01-31 2:30 ` Tom
2013-02-04 12:55 ` Dave Chinner
2013-02-05 18:22 ` Tom
2013-02-05 21:32 ` Dave Chinner
2013-02-05 23:05 ` Tom
2013-02-06 4:08 ` Tom
2013-02-06 23:51 ` Dave Chinner
2013-02-07 4:18 ` Tom
2013-01-31 7:35 ` Stefan Ring
-- strict thread matches above, loose matches on Subject: below --
2013-01-31 2:34 Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5108DFE0.2060908@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox