Date: Fri, 24 Apr 1998 14:43:52 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-advocacy@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: *** Real Action Item: SPECweb Message-ID: <Pine.BSF.3.95.980424135722.28001P-100000@alive.znep.com> In-Reply-To: <199804241831.LAA00871@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Apr 1998, Mike Smith wrote:
> > On Fri, 24 Apr 1998, Mike Smith wrote:
> >
> > > > I have spoken to several of my lower level sal> Once we have the system spec'd, I have no doubt I can get hardware, because it's
> > > > very obvious that this will be an enormous bonanza for all major corporate
> > > > sponsors.
> > >
> > > - Dual 400MHz PII's (I think this will finally pull ahead of the 1M
> > > cache 233MHz P6'en).
> >
> > I really doubt that dual processors will give you any advantage even if
> > you were willing to use current. I'm not up on the current state of
> > FreeBSD SMP, but if it isn't beyond the level of a single spin lock on
> > kernel code, you won't win and you could even lose by going SMP. You can
> > actually get worse performance when using SMP on stable Linux kernels than
> > not using it.
>
> That depends on where the load is; if it's in kernel space then I'd be
> inclined to agree with you (and I'd say that the 1M P6 would probably
> be a contender there).
>
> If the load is even substantially in user space, then the story seems
> to change entirely. If nothing else, having the second CPU would be
> educational from our perspective.
Webserving is very kernel heavy and I would doubt it would gain at all
from SMP on a system using a single spin lock. That has been my
experience on numerous operating systems. AFAIK, the issues that have to
be dealt with in the SMP code to fix this are really clear (not
necessarily the way to do it, but the concepts) so I don't think there
would be a big benefit.
>
> > > - A BX-based board with as much memory as the PII's will cache.
> > > - All of the OS, and if possible all of the web data in MFS. This may
> > > involve the biggest, nastiest PicoBSD config you can imagine.
> >
> > The size of the SPECweb dataset actually changes with the "expected"
> > benchmark results. You are probably looking at... 500-750 megs or so.
>
> What sort of working-set size is the system likely to have? On a 1GB
> system, you could probably get away with an MFS like that.
It depends on how much more expensive reading from a MFS file system
is than reading from the buffer cache.
>
> > I don't think you can use MFS, there are certain restrictions on what you
> > can and can't do when reporting SPECweb numbers.
>
> 8( Ok, solid-state SCSI disks then.
There is a requirement that:
The server utilizes stable storage for all data files and server
logs. The log file records must be written to non-volatile storage
at least as often as once per 60 seconds.
A description of the rules is at http://www.spec.org/osg/web96/runrules.html
>
> > > - If it won't all work in an MFS, a DPT controller and a small farm of
> > > 10000rpm fibrechannel disks. Otherwise, the disk is irrelevant.
> > > - No swap.
> >
> > No, you want swap especially if using Apache (because of all the COW
> > pages). It won't be "really" used, but you still need it.
>
> I'm not sure I follow this, but I may be missing a nuance in our
> handing of COW.
Swap is allocated for pages flagged COW, at the time the pages are
mapped, no? If you don't have swap...
Because of the design of Apache (more so on servers with more config
info, thousands of vhosts, etc.) where the child processes are forked
from the parent, you can end up with a lot of COW pages.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980424135722.28001P-100000>