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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox