Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 May 2000 09:02:39 -0600
From:      Chuck Paterson <cp@bsdi.com>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        arch@freebsd.org
Subject:   Re: Short summary 
Message-ID:  <200005251502.JAA24170@berserker.bsdi.com>

next in thread | raw e-mail | index | archive | help
}Chuck,
}
}What sorts of workloads have you made comparisons between the SMPng &
}Giant-lock uniprocessor kernels on?  Do you have any quantative
}results that state what the cost or benefit of SMPng on a uniprocessor
}in a heavily interrupt driven environment is?

	We have done virtually no performance testing, our
kernel is just barely getting to the point where we can to this testing.
There is every reason to expect it to do well, but it just
isn't known.  We have one customer looking at it for these sorts of
things and so far the results are positive. 

}I'm curious about tortuous workloads like a firewall between multiple
}100Mb or Gigabit network segments, or a saturated Web (or NFS) server
}w/multiple disk controllers and network adapters (Eg, workloads like
}the imfamous Mindcraft benchmark (in single CPU mode), or SPEC SFS97
}or SPEC WEB99).
}

	We currently run NFS under a single lock. I have no
clue when we BSDI will do anything about this. The NFS code which
is in both FreeBSD and BSD/OS is going to have a major wacking to
multi thread it. There are structural problems which are not present
in the other file systems. Something is going to have to be done
with the huge inline macros so they know what mutex to release.
The sharing of macros between server and client makes it even
harder. On a related subject talk about blowing cache lines for nothing. 
I have done just a very few tests and server and client appear to be just
slightly faster. The client was (3.5% in one test) in the test I
still have numbers for.


	As a firewall there is yet another issue. You would
like to have multiple processors doing checksums at the
same time. However, you also don't want to re-order packets.
There is also the small issue of

static struct   sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
static struct   route ipforward_rt;

	not exactly MP ready. The above is from FreeBSD, BSD/OS
has this problem also.

Chuck


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005251502.JAA24170>