[lkml]   [2005]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Lmbench-users] Re: pipe performance regression on ia64
It would be good if you copied me directly since I don't read the kernel
list anymore (I'd love to but don't have the bandwidth) and I rarely read
the lmbench list. But only if you want to drag me into it, of course.

Carl and I both work on LMbench but not very actively. I had really
hoped that once people saw how small the benchmarks are they would
create their own:

work ~/LMbench2/src wc bw_pipe.c
120 340 2399 bw_pipe.c

I'm very unthrilled with the idea of adding stuff to the release benchmark
which is OS specific. That said, there is nothing to say that you can't
grab the benchmark and tweak your own test case in there to prove or
disprove your theory.

If you want to take LMbench and turn it into LinuxBench or something like
that so that it is clear that it is just a regression test for Linux then
hacking in a bunch of tests would make a ton of sense.

But, if you keep it generic I can give you output on a pile of different
OS's on relatively recent hardware since we just upgraded our build

Welcome to, a 2.1Ghz Athlon running Red Hat 5.2.
Welcome to, a 2.16Ghz Athlon running Red Hat 6.2.
Welcome to, a 2.1Ghz Athlon running Red Hat 7.1.
Welcome to, a 2.1Ghz Athlon running Red Hat 9.
Welcome to, a 2Ghz AMD 64 running Fedora Core 1.
Welcome to, a 552Mhz PA8600 running Debian 3.1
Welcome to, a 400Mhz PowerPC running Yellow Dog 1.2.
Welcome to, a dual 1.2Ghz G4 running MacOS 10.2.8.
Welcome to a 440 Mhz Sun Netra T1 running Debian 3.1.
Welcome to, a 500Mhz AlphaPC running Red Hat 7.2.
Welcome to, a dual 800Mhz Itanium running Red Hat 7.2.
Welcome to, a 2.17Ghz Athlon running FreeBSD 2.2.8.
Welcome to, a 1.8Ghz Athlon running FreeBSD 3.2.
Welcome to, a 1.8Ghz Athlon running FreeBSD 4.1.
Welcome to, a 1.6Ghz Athlon running FreeBSD 5.1.
Welcome to, a 2.17Ghz Athlon running OpenBSD 3.4.
Welcome to, a 1Ghz Athlon running NetBSD 1.6.1.
Welcome to, a 1.8Ghz Athlon running SCO OpenServer R5.
Welcome to, a 440Mhz Sun Ultra 10 running Solaris 2.6
Welcome to, a dual 1Ghz PIII running Solaris 2.7.
Welcome to, a 195Mhz MIPS IP28 running IRIX 6.5.
Welcome to, a dual 800Mhz MIPS running Debian 3.0.
Welcome to, a 552Mhz PA8600 running HP-UX 10.20.
Welcome to, a dual 550Mhz PA8500 running HP-UX 11.11.
Welcome to, a 400Mhz PA8500 running HP-UX 11.11.
Welcome to, a 332Mhz PowerPC running AIX 4.1.5.
Welcome to, a 250Mhz MIPS running Linux 2.0.34.
Welcome to, a 233Mhz StrongARM running Linux 2.2.
Welcome to, a 600Mhz Alpha running Tru64 5.1B.
Welcome to, a 2.1Ghz Athlon running Windows XP.

On Tue, Jan 18, 2005 at 12:17:11PM -0800, Linus Torvalds wrote:
> On Tue, 18 Jan 2005, David Mosberger wrote:
> >
> > >>>>> On Tue, 18 Jan 2005 10:11:26 -0800 (PST), Linus Torvalds <> said:
> >
> > Linus> I don't know how to make the benchmark look repeatable and
> > Linus> good, though. The CPU affinity thing may be the right thing.
> >
> > Perhaps it should be split up into three cases:
> >
> > - producer/consumer pinned to the same CPU
> > - producer/consumer pinned to different CPUs
> > - producer/consumer lefter under control of the scheduler
> >
> > The first two would let us observe any changes in the actual pipe
> > code, whereas the 3rd case would tell us which case the scheduler is
> > leaning towards (or if it starts doing something real crazy, like
> > reschedule the tasks on different CPUs each time, we'd see a bandwith
> > lower than case 2 and that should ring alarm bells).
> Yes, that would be good.
> However, I don't know who (if anybody) maintains lmbench any more. It
> might be Carl Staelin (added to cc), and there used to be a mailing list
> which may or may not be active any more..
> [ Background for Carl (and/or lmbench-users):
> The "pipe bandwidth" test ends up giving wildly fluctuating (and even
> when stable, pretty nonsensical, since they depend very strongly on the
> size of the buffer being used to do the writes vs the buffer size in the
> kernel) numbers purely depending on where the reader/writer got
> scheduled.
> So a recent kernel buffer management change made lmbench numbers vary
> radically, ranging from huge improvements to big decreases. It would be
> useful to see the numbers as a function of CPU selection on SMP (the
> same is probably true also for the scheduling latency benchmark, which
> is also extremely unstable on SMP).
> It's not just that it has big variance - you can't just average out many
> runs. It has very "modal" operation, making averages meaningless.
> A trivial thing that would work for most cases is just a simple (change
> the "1" to whatever CPU-mask you want for some case)
> long affinity = 1; /* bitmask: CPU0 only */
> sched_setaffinity(0, sizeof(long), &affinity);
> but I don't know what other OS's do, so it's obviously not portable ]
> Hmm?
> Linus
> _______________________________________________
> Lmbench-users mailing list

Larry McVoy lm at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2005-03-22 14:09    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean