Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@cup.hp.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] performance
Date: Fri, 29 Dec 2000 22:13:32 -0800	[thread overview]
Message-ID: <200012300613.WAA24743@milano.cup.hp.com> (raw)
In-Reply-To: Your message of "Wed, 27 Dec 2000 18:08:29 PST." <E14BL04-0002Zj-00@the-village.bc.nu>


Alan,
Interesting comments. I had to think about them for a bit.

Alan Cox wrote:
> Specweb is basically a con. Its not a materially valuable benchmark.
> It benches how fast your irq handler path is, how fast your memory cache
> is, how good your DMA transfers are. It has almost nothing to do with how
> good a web server the box is.

At some level, all benchmarks are bogus. Bogomips encapsulates the issue.
Taking the benchmarks out of context is when the con game starts.
Isn't Specweb just one aspect of what makes a good webserver?
Others include cost, size, security, manageability, reliability, etc.
It just seems CPU/Memory/IO "bandwidth" and utilization (efficiency) are
valid things to measure. An outsiders perspective is Specweb attempts to
encapsulate those numbers with a representative workload.

Marketing drives most benchmarking I've been involved in.
And Marketing targets the more ignorant (but not too poor) customers. 
Smart (and rich) customers use specific benchmarks make a "short list"
and then measure *their* application performance.
HP has several "Capacity Planning Centers" just for those customers.

[ deleted comment about putting webserver in kernel ]

> So it comes down to - tuning the network card driver, tuning the IRQ path, 
> making sure the cache handling is optimal. The rest consists of loading the
> machine with 8Gbytes of RAM, using obscenely smart ethernet cards and having
> good memory bandwidth.
> 
> The 64bit pa-risc boxes have the hardware for it, in fact they have better 
> hardware for it than x86. All you have to do is write better tlb, irq and pci
> handling code than the HP/UX engineering team 8).

Given only a handful of people know the PARISC CPU/TLB as well as jsm,
and I (re)wrote the HPUX PCI code, I suggest long term performance
gains will be found in linux VM/PM (and other "architected" stuff like
atomic operations - which will always suck on parisc) and drivers.
(My definition of drivers includes networking stack and NIC device drivers).
Short term goal is to optimize existing parisc-specific code around
existing architecture.

[ /rant on ]
The HPUX engineering team is not lacking in talent - just opportunity to
make the zillions of small changes required to improve scalability and
reduce CPU utilization. Any single change resulting in less than 2%
performance improvement on something like SpecWeb is very hard to get
into HPUX kernel.
[ /rant off ]

grant

  parent reply	other threads:[~2000-12-30  6:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-27 17:05 [parisc-linux] performance Alex deVries
2000-12-27 17:52 ` Grant Grundler
2000-12-27 18:08 ` Alan Cox
2000-12-27 18:53   ` Alex deVries
2000-12-30  6:13   ` Grant Grundler [this message]
2000-12-30 16:50     ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2000-03-01  5:50 [parisc-linux] Performance T. Martin
2000-03-01 14:18 ` Michael Shalayeff
2000-03-02  3:54   ` Steve Shack

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=200012300613.WAA24743@milano.cup.hp.com \
    --to=grundler@cup.hp.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=parisc-linux@thepuffingroup.com \
    /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