Re: [aclug-L] ntmag
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Would it be worthwhile to get the "free" solaris 7 for a dual P5
motherboard (assuming it's supported) or are the resourse overheads too
daunting for a private user? I've got a dual P5 ASUS and simply gave up
on using it. Before I dump the board entirely I'm trying to figure out if
it's worth the effort/expense to get apps that will use the SMP feature.
At 01:20 AM 5/4/99 -0300, you wrote:
>I may be able to help on a couple points in the article, although
>there is much that I am not totally clear on, either. I haven't
>taken a close look at MP support in Linux 2.2, so I don't know
>how fine-grained the locking is, or whether there is a LWP (light
>weight process) concept and its associated interfaces. And I know
>as little about NT as possible.
>Some basic background: AT&T started working on UNIX MP support
>for the SVR4 MP release, something like 10 years ago. The legacy
>of that work shows up in UnixWare, Solaris, Irix, HP-UX, and
>various other commercial Unix OS. Linux introduced very primitive
>MP support in 2.0: there was a single lock around the entire
>kernel. Linux 2.2 introduces more fine-grained locking (what
>the article refers to as re-entrant kernel functions). However,
>there are still several large subsystems in Linux that are
>guarded by single locks: in particular, the file system and
>the TCP/IP stack. (The article states that the lock is on the
>read and write system calls. This may be correct: my information
>is simply that ext2fs and tcp/ip are still single-threaded.)
>The short story here is that commercial Unix has about an 8 year
>head start in terms of MP support: all other factors being equal,
>a commercial Unix will scale progressively better as more CPUs
>are added. There's no real mystery to this. One major way to
>improve MP performance is to replace big bottleneck locks with
>finer-grained locking, so the CPUs run into each other less
>frequently. Since each bottleneck you remove makes the next
>most frequent bottleneck all the more visible, progress in MP
>performance in incremental over time.
>The same thing happens with other performance bottlenecks. Most
>commercial Unix have support for asynch I/O, and many support
>sendv (a system call which allows files to be copied straight
>to a network socket without a sidetrip into user space; this is
>what NT calls sendfile).
>Regardless of how Linux 2.2 stacks up, I have no doubt that
>some not-too-distant future Linux release will tackle all of
>these issues. The only thing that has to happen is that Linux
>hackers have to get their hands on larger MP equipment: this
>is starting to happen, as evidenced by Penguin Computing's
>announcement of a 8-Xeon Linux server.
>I think the reasonable conclusion from all this is that if you
>really need 4+ CPUs and really need to get every cycle out of
>them, go with a commercial Unix system. On the other hand, if
>you can get by with a little less performance, stick with Linux
>(even in a 4-way MP). In the long run you'll be in better hands.
>My impression is that, strictly in terms of performance, NT is
>somewhere between commercial Unix and Linux. Microsoft has spent
>a lot of money, both in building MP support and in benchmark
>tuning, but they haven't come up with anything fundamentally
>superior to Unix. My impression is that the emphasis in the
>article on kernel threads is part "benchmark special" (some
>finely tuned hack that favorably distorts the benchmark score
>without providing any generally useful value), and part diversion
>from the fact that Microsoft's process model is notoriously weak.
>On the other hand, NT has so many negatives that I wouldn't
>give any performance claims a second thought.
>Quite frankly, I find that most benchmarks are so unrepresentative,
>and that the tunings for them are so unorthodox, that I think it
>would be foolish to give them more than a moment's thought. For
>example, the current vogue in SpecWeb is to mount the file system
>read-only (since SpecWeb only reads files) and to move the httpd
>server into kernel space to avoid context switches (which is
>possible because the benchmarks doesn't execute CGI scripts).
>This is supposed to be an honest test of ISP performance?
>As for TPC-C, check out:
>The new champ, at 115395, is a 64-CPU Sparc, with 64GB memory and
>1732 disks. The best NT score is down at 33935, a Compaq with
>16-Xeon (4x4 cluster), with 13GB memory and 388 disks.
>BTW, a good place to check up on the progress of Linux in
>big-time Enterprise is:
>> a man i used to work with in austin is considering learning linux.
>> his day job is as an nt administrator.
>> today he sent me this article asking me what i thought .
>> in truth most of what the author is talking about is over my head.
>> my understanding is that linux has always had support for SMP,
>> with 2.2 it is more efficient.
>> i would like to give him some constructive feed back, but
>> once again this is over my head.
>> not too much nt bashing please :-).
>> Oh I've slipped the surly bonds of dos
>> and danced the skies on LINUX silvered wings.
> * Tom Hull :: thull@xxxxxxxx :: http://www.ocston.org/~thull
- Re: [aclug-L] ntmag, (continued)
- Re: [aclug-L] ntmag, James G., 1999/05/03
- Re: [aclug-L] ntmag, Mohammad Islam, 1999/05/03
- Re: [aclug-L] ntmag, Tom Hull, 1999/05/04
- Re: [aclug-L] ntmag, phrostie, 1999/05/04
- Re: [aclug-L] ntmag, John Goerzen, 1999/05/08
- Re: [aclug-L] ntmag,
Jeffrey L. Hansen <=
- Re: [aclug-L] ntmag, Greg House, 1999/05/06