From: "Dan Maas" <dmaas@dcine.com>
To: "Bryan Mayland" <bmayland@leoninedev.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] again: Re: Athlon kernel crash (i686 works)
Date: Wed, 10 Oct 2001 00:06:29 -0400 [thread overview]
Message-ID: <07d601c15140$f07c2870$1a01a8c0@allyourbase> (raw)
In-Reply-To: <fa.efssf0v.146031s@ifi.uio.no>
> I've run several LMbench tests against both 686-optimized
> and Athlon-optimized kernels. The results waver across multiple
> tests, one kernel winning some tests one time and losing the next,
> but the values are all close.
The benefits of the kernel Athlon optimizations are higher memory bandwidth
for bulk copies/clears and less cache pollution. But LMbench isn't going to
show any difference, because its tests use generic x86 mem*() functions, not
Athlon-optimized SSE memory routines like in the Athlon kernel.
*Local* Communication bandwidths in MB/s - bigger is better
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read
write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- ----
-
Athlon-1 Linux 2.4.10- 847. 685. 311. 332.4 501.3 176.2 206.2 471.
342.5
Athlon-2 Linux 2.4.10- 882. 586. 187. 331.6 510.2 177.6 207.1 484.
343.5
i686-1 Linux 2.4.10- 863. 586. 299. 320.0 510.2 176.3 206.6 472.
342.6
i686-2 Linux 2.4.10- 874. 318. 199. 319.6 520.2 177.7 206.8 486.
343.5
It should be obvious that LMbench uses sub-optimal memory routines, since
the numbers for "Bcopy" and "Mem read/write" bandwidth are so much lower
than pipe and AF UNIX bandwidths! (the pipe/UNIX tests are basically
equivalent to Bcopy, plus extra user<->kernel transitions and context
switches).
The only cases where I'd expect the Athlon kernel to do better on LMbench
are essentially kernel memcpy() benchmarks - pipe and AF UNIX bandwidths.
I'm not sure if the kernel pipe and UNIX socket code actually uses
Athlon-optimized routines; in any case the small buffer sizes (eg 4KB for
pipes) could be hiding any performance gain.
Regards,
Dan
next parent reply other threads:[~2001-10-10 4:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.efssf0v.146031s@ifi.uio.no>
2001-10-10 4:06 ` Dan Maas [this message]
2001-10-10 8:09 ` [PATCH] again: Re: Athlon kernel crash (i686 works) VDA
2001-10-09 13:00 Bryan Mayland
2001-10-09 14:28 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2001-10-09 9:32 Marco Berizzi
2001-10-09 11:45 ` [PATCH] again: " VDA
2001-10-09 11:04 ` Marco Berizzi
2001-10-09 11:55 ` Gergely Tamas
2001-10-09 13:59 ` Alejandro Conty
2001-10-09 14:19 ` Brian Gerst
[not found] ` <Pine.LNX.4.33.0110091611050.20120-100000@falka.mfa.kfki.hu>
2001-10-09 14:52 ` Alejandro Conty
2001-10-09 14:52 ` Gergely Tamas
2001-10-09 21:12 ` Dan Hollis
2001-10-09 22:22 ` Luigi Genoni
2001-10-09 14:27 ` Fabio Coatti
2001-10-09 21:11 ` Dan Hollis
2001-10-09 22:19 ` Luigi Genoni
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='07d601c15140$f07c2870$1a01a8c0@allyourbase' \
--to=dmaas@dcine.com \
--cc=bmayland@leoninedev.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.