Re: [Lse-tech] Take that! Linux beats MS in benchmark test

Mike Kravetz wrote:
>
> On Thu, May 17, 2001 at 11:16:34AM -0700, Ruth Forester wrote:
> > Linux breaks the TPC barrier...
> >
> > http://www.zdnet.com/zdnn/stories/news/0,4586,2760874,00.html
> >
>
> It is interesting (from a scalability standpoint) that this
> benchmark was run on a cluster of 4 CPU systems. Did anyone
> try to run it on a single 8 CPU system? This would make an
> interesting comparison as most of the other results are on
> 8 CPU systems running Windows/SQL.
No, this was not attempted at SGI: we don't have 8 CPU boxes,
well, not on IA32 ;-)
>
> I have had problems running Linux/DB2 on 8 CPU systems due
> to contention in the timer subsystem. I have been able to
> work around this by applying Ingo Molnar's timer patches.
> Does anyone know if this patch is in SGI's Propack 1.5?
I don't recall the exact details, but at some point
we did use that patch ... I am not sure whether
the final run that produced the record numbers had the
patch. No, Propack 1.5 wouldn't have the patches.
cheers,
ananth.
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

On Thu, May 17, 2001 at 11:16:34AM -0700, Ruth Forester wrote:
> Linux breaks the TPC barrier...
>
> http://www.zdnet.com/zdnn/stories/news/0,4586,2760874,00.html
>
It is interesting (from a scalability standpoint) that this
benchmark was run on a cluster of 4 CPU systems. Did anyone
try to run it on a single 8 CPU system? This would make an
interesting comparison as most of the other results are on
8 CPU systems running Windows/SQL.
I have had problems running Linux/DB2 on 8 CPU systems due
to contention in the timer subsystem. I have been able to
work around this by applying Ingo Molnar's timer patches.
Does anyone know if this patch is in SGI's Propack 1.5?
--
Mike Kravetz mkravetz@...
IBM Linux Technology Center

Mike Kravetz wrote:
>
> On Thu, May 17, 2001 at 11:16:34AM -0700, Ruth Forester wrote:
> > Linux breaks the TPC barrier...
> >
> > http://www.zdnet.com/zdnn/stories/news/0,4586,2760874,00.html
> >
>
> It is interesting (from a scalability standpoint) that this
> benchmark was run on a cluster of 4 CPU systems. Did anyone
> try to run it on a single 8 CPU system? This would make an
> interesting comparison as most of the other results are on
> 8 CPU systems running Windows/SQL.
No, this was not attempted at SGI: we don't have 8 CPU boxes,
well, not on IA32 ;-)
>
> I have had problems running Linux/DB2 on 8 CPU systems due
> to contention in the timer subsystem. I have been able to
> work around this by applying Ingo Molnar's timer patches.
> Does anyone know if this patch is in SGI's Propack 1.5?
I don't recall the exact details, but at some point
we did use that patch ... I am not sure whether
the final run that produced the record numbers had the
patch. No, Propack 1.5 wouldn't have the patches.
cheers,
ananth.
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

On Thu, May 17, 2001 at 11:45:31AM -0700, Mike Kravetz wrote:
> I have had problems running Linux/DB2 on 8 CPU systems due
> to contention in the timer subsystem. I have been able to
> work around this by applying Ingo Molnar's timer patches.
I'm curious: did you gather any data on which subsystem/syscall stressed
timers that much?
-Andi

On Thu, May 17, 2001 at 09:48:38PM +0200, Andi Kleen wrote:
> On Thu, May 17, 2001 at 11:45:31AM -0700, Mike Kravetz wrote:
> > I have had problems running Linux/DB2 on 8 CPU systems due
> > to contention in the timer subsystem. I have been able to
> > work around this by applying Ingo Molnar's timer patches.
>
> I'm curious: did you gather any data on which subsystem/syscall stressed
> timers that much?
I'm pretty sure this is due to heavy use of 'nanosleep()' in
their implementation of user level synchronization primitives
(latch). In such implementations code spins at user level
and occasionally calls into the kernel in the hope of giving
CPU cycles to the thread that holds the resource it needs.
Anyone who has a better understanding of this, please feel free
to correct me.
The ability to develop efficient user level synchronization
primitives on Linux seems to be a concern of most database
developers. Recall Oracle's requirements presentation at the
2.5 kernel workshop. They want a 'no preempt' primitive to
help with their implementation. Linus (and most of the community)
didn't go for this and instead suggested the development of
Light Weight User Level Semaphores.
-
Mike Kravetz mkravetz@...
IBM Linux Technology Center

On Thu, May 17, 2001 at 02:21:19PM -0700, Mike Kravetz wrote:
<snip>
> developers. Recall Oracle's requirements presentation at the
> 2.5 kernel workshop. They want a 'no preempt' primitive to
> help with their implementation. Linus (and most of the community)
> didn't go for this and instead suggested the development of
> Light Weight User Level Semaphores.
Has Oracle given a response to that solution? Will it give them the
functionality they need or is there some additional design needed?
-Nathan

On Thu, May 17, 2001 at 02:28:05PM -0700, Nathan Dabney wrote:
> On Thu, May 17, 2001 at 02:21:19PM -0700, Mike Kravetz wrote:
> > Linus (and most of the community)
> > didn't go for this and instead suggested the development of
> > Light Weight User Level Semaphores.
>
> Has Oracle given a response to that solution? Will it give them the
> functionality they need or is there some additional design needed?
>
> -Nathan
It 'may' be something that will work for them. Since the
functionality is not clearly defined, they can't be sure.
I have forwarded Linus's proposal from the kernel mailing
list to them. Two must have requirements from them are,
- A timeout mechanism
- The semaphores must be inter-process (work between threads
in different processes).
The proposals thrown around on the mailing list seem to meet
these requirements. However, until someone comes up with an
initial design/implementation we can't be sure. I plan on
looking into this as soon as I get some time (said that in the
past also :).
--
Mike Kravetz mkravetz@...
IBM Linux Technology Center

On Thu, May 17, 2001 at 04:36:21PM -0700, Mike Kravetz wrote:
> On Thu, May 17, 2001 at 02:28:05PM -0700, Nathan Dabney wrote:
> > On Thu, May 17, 2001 at 02:21:19PM -0700, Mike Kravetz wrote:
> > > Linus (and most of the community)
> > > didn't go for this and instead suggested the development of
> > > Light Weight User Level Semaphores.
> >
> > Has Oracle given a response to that solution? Will it give them the
> > functionality they need or is there some additional design needed?
> >
> > -Nathan
>
> It 'may' be something that will work for them. Since the
> functionality is not clearly defined, they can't be sure.
> I have forwarded Linus's proposal from the kernel mailing
> list to them. Two must have requirements from them are,
> - A timeout mechanism
> - The semaphores must be inter-process (work between threads
> in different processes).
Ask we don't make a difference between processes and threads in
Linux I don't see a problem - if CLONE_VM is not given just
a shared mmap should be needed.
Christoph
--
Of course it doesn't work. We've performed a software upgrade.

On Tue, 22 May 2001, John Wright wrote:
> As I mentioned on the last LSE con-call, Doug Nelson ran this
> benchmark and is willing to speak to technical questions as to
> what the bottlenecks were, what patches were used, etc.
That would be _wonderful_ information to have.
Having the statistics from the few folks with the
equipment and time to run these tests available to all
developers will probably be a nice help in making it
possible to fix the measured bottlenecks.
(and, for people like me, to identify them)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/http://distro.conectiva.com/
Send all your spam to aardvark@... (spam digging piggy)