[GRLUG] large systems performance
Bob Kline
bob.kline at gmail.com
Fri Nov 16 01:35:34 EST 2007
On Nov 16, 2007 1:24 AM, Michael Mol <mikemol at gmail.com> wrote:
> On Nov 16, 2007 1:15 AM, Bob Kline <bob.kline at gmail.com> wrote:
> > On Nov 16, 2007 12:57 AM, Tim Schmidt <timschmidt at gmail.com> wrote:
> > > On Nov 16, 2007 12:45 AM, Bob Kline <bob.kline at gmail.com> wrote:
> > > > If running Linux, which version?
> > So would you guess that even more
> > processors would help? With your
> > load profile that is?
> >
> > It's not impossible that even a desktop
> > will have hundreds of CPUs one day.
> > I have no idea whether Linux could
> > support that. But with the concept of
> > one process per processor, without much
> > swapping while in typical use, one
> > would see even more improvement.
> > Swapping always creates overhead, so
> > the best way to reduce overhead is to not
> > swap where possible. Including letting
> > other jobs wait in some circumstances
> > if they are not real time.
>
> The O(1) scheduler brought in with the start of the 2.6 kernel series
> means that you won't see a performance degradation with the addition
> of more cores, if you're running independent tasks. You might see a
> limit to performance improvements if your software isn't written
> right, though; It's deceptively easy to write bad multi-threaded code
> that hangs up on one or two locks.
>
> --
> :wq
>
>
Well, no OS, no matter how well
written, can do much about the
applications people run on it.....
For now most of us probably can
assume the core parts of the OS are
not the problem if performance suffers.
-Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20071116/0238b668/attachment-0001.htm
More information about the grlug
mailing list