Re: benchmarking squid on solaris/x86

From: Lincoln Dale <ltd@dont-contact.us>
Date: Thu, 21 Mar 2002 02:11:56 -0800

Adrian,

far be it for me to get into a flamewar, but there's a few things here that
should probably be corrected ....

At 02:34 AM 20/03/2002 -0700, Adrian Chadd wrote:
> > Does anyone have experience with solaris on x86? I'm trying to
> > decide if its an inherent limitation, or should solaris be able to
> > keep up with linux on the same hardware?
..
>Also, remmember that Solaris _is_ compiled for SMP performance
>out of the box, so things will be slower on a single CPU.

actually, Solaris generally _isn't_ compiled for SMP. you're confusing
pre-emption with SMP.
also note that the big-iron sun hardware with >4 CPUs isn't SMP but rather
CC-NUMA.

At 04:51 PM 20/03/2002 -0700, Adrian Chadd wrote:
>On Wed, Mar 20, 2002, Henrik Nordstrom wrote:
> > To me it is a bit odd that Linux do have RT signal I/O, but not a
> > working /dev/poll. But I guess RT signal I/O was more fun to
> > implement..

actually, linux does have a /dev/poll & /dev/epoll.
sure, they're not part of the standard kernel, but its trivial to add it.

>Linux seems to suffer from the "NIH" syndrome. Ie, if its not
>invented or implemented here, we don't like it.

not true on two counts:
  [1] linux has SIGIO -- but SIGIO predates its implementation in linux by
quite a bit.
  [2] kqueued/kevent is only solves event-notification.

as for [1], SIGIO sucks. if you really want to know the gory details why, see
   http://marc.theaimsgroup.com/?l=linux-kernel&m=100888541205739&w=2
   http://marc.theaimsgroup.com/?l=linux-kernel&m=100888593806860&w=2
   http://marc.theaimsgroup.com/?l=linux-aio&m=100888973615146&w=2

>Search the linux-kernel list archives for the discussions
>about /dev/poll and kqueue, and see what people have to say.
>Whether its the "best" or not really isn't relevant - its
>a step in the right direction. A very big step. :)

as for [2], its only solving part of what needs to be done. once you have
scalable event-notification and you've fixed up disk i/o bottlenecks,
you'll then discover that your next bottleneck is that you're running out
of memory bandwidth due to the large number of memory-copies that go on for
every read()/write(). at that point, you'll see that you need some other
mechanism.

if you're really interested in following this, take a look at linux-aio ...

cheers,

lincoln.
Received on Thu Mar 21 2002 - 03:21:43 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:52 MST