🚀 go-pugleaf

Totally Lost wrote:
> 
> The work done by Tomohiro Kawada and others has been interesting.

<some verbiage and cache scaling diagram eliminated>

> SunOS svr20 5.5.1 Generic sun4m sparc SUNW,SPARCstation-20
>
> This particular machine didn't have a lot of
> memory and started paging above 32M, with 32K L1 and 1024K L2 cache
> sizes. Increasing the working set by a single cache line
> often reduces the performance to the next larger (and slower)
> memory object.

 
How closely does this system - it's hardware, software, and OS resemble the x86
SMP hardware, and Linux or NT?  Is it truly a good analogy?  For which OS? both?


> In a real system, there are many sources that scale into the working
> set size(s). The size of the active interrupt service routines and
> OS scheduler are often near the size of L1/L2 caches on many X86
> systems, 

Which systems are we talking about here?  486? PII? Celeron? Xeon? PPro? Under
NT? Linux?  How much variability is there between these?  Aren't the PPro, PII,
Celeron, and Xeon rather different in their cache to CPU relationships? and thus
the observed situation arises that Celerons perform nearly identically to their
cousins - despite their small cache, as unlike all the other chips, the cache is
actually an integrated part of the processor silicon and runs at full speed -
even the Xeon, with full-speed cache, the L2 is a separate piece of silicon
connected via the PCB.  The closest is the PPro perhaps...  An attribute that
would appear to be a rather severe limitation turns out to be less so than one
might predict or expect.

> thus each interrupt flushes the cache and effectively runs
> at memory or L2 cache speeds. In an SMP system, both CPU's have to
> share the memory performance. If the L1/L2 caches are too small, then
> two processors are worse than one, because they will flush each other
> with distributed interrupts. The cost of flushing the cache by context
> switches and interrupts is two 2X ... memory cycles required to bring
> in the new context/interrupt plus the memory cycles required to replace
> the active process memory on exit. One reason that X86 SMP servers
> may scale, is that network interrupt loads that flush a uniprocessor,
> only impact one processor in a multiprocessor system ... especially
> if the interrupts are bound to a single processor. Ditto for the disk
> subsystems.

So this is an advantage of the x86 architecture as compared to your Sun
example?  

<...>

> Understanding the locality and working set sizes, some X86 vendors
> have post processed their kernel builds to improve locality and
> placement. The work done by the SCO Unixware team on the object code
> segments has produced remarkable results. These vendors often have
> large kernels and feature sets, with same/better overall performance.

So it should be possible to optimize Linux for Celeron SMP - correct?


> Celron's with their 128K L2 cache can easily produce worse performance
> under modest to heavy load than a single processor in an SMP system.


Is this conjecture on your part or are you referring to some actual situation
that you are familiar with?


> In many server systems, even dual PII's with 512K L2 caches fail to
> scale or produce negative results under modest to heavy work loads.


What systems running what OS with what apps? A specifics might clarify your
example...


> In some applications, even Xenon's large caches fail to scale or
> produce negative results in comparision to uniprocessors of the same
> architecture. Simply put, it's not uncommon to find applications where
> two processors trashing the caches with SMP interrupts or shared memory
> produce much worse performance than the same system with only a single
> processor enabled.


Or: mis-matching of hardware and software will lead to less than optimal results
- yes this is a reasonable generalization. One shouldn't try to run Word 2K on a
286 for instance...


> Linux is not well multi-threaded, and has a pretty large foot print
> with very little locality in either the OS or it's primary applications.


Is this the most current information?
What about NT?


> I would expect that for many users, dual Celeron's may have a negative
> performance impact much of the time.


Well, this would be rather easy to check, would it not?  Why rely on conjecture?


> To observe that Dual Celron's produce an observed improvement under
> certain lightly loading applications may be true. To assert that
> they scale under modest to heavy work loads is probably a huge mistake.
> To expect that they will scale well under Linux with heavy loads is
> almost certainly folly.


To make broad assertions with no examples is a relatively easy nag to ride -
right?  Much more productive for someone to do some tests, post the results and
determine the actual limitations and/or advantages of particular configurations.

I am perfectly willing to entertain the possibility that some of your assertions
may be on the money - but you really didn't offer more than some general
theoretical arguments and cautions.  Well, I don't have a Linux server to run
through the paces, so I'm not much help either...

CB

> 
> John Bass
> UNIX Systems Consultant
> 
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---


  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----