From owner-freebsd-hackers Fri Jun 11 20:50:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mag.ucsd.edu (mag.ucsd.edu [132.239.34.96]) by hub.freebsd.org (Postfix) with ESMTP id 713E814F89 for ; Fri, 11 Jun 1999 20:50:19 -0700 (PDT) (envelope-from billh@mag.ucsd.edu) Received: (from billh@localhost) by mag.ucsd.edu (8.8.8/8.8.8) id UAA01670; Fri, 11 Jun 1999 20:45:19 -0700 (PDT) From: Bill Huey Message-Id: <199906120345.UAA01670@mag.ucsd.edu> Subject: Re: High syscall overhead? To: wes@softweyr.com (Wes Peters) Date: Fri, 11 Jun 1999 20:45:19 -0700 (PDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <3761BD22.782508D3@softweyr.com> from "Wes Peters" at Jun 11, 99 07:51:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Try a more meaningful benchmark, one that actually does something in > the kernel before returning, and see how they do. Try calling kill > or socket/close a few hundred thousand times and see how they do. Or that horribily impracticle wake-one semantics implemented under SMP for the accept() function with recent Linux kernels to prevent overscheduling. Or another really useless thing like releasing a MP lock in the TCP/IP stack the increases user space copies by a factor of 4 times in the Linux kernel. FreeBSD still using a single big kernel lock which slows down certain unimportant things like getting every so slow course grained kernel lock ? Are things breaking with all the new changes in the FreeBSD kernel ? Uh, "yes" to the two above questions ? > Wes Peters Softweyr LLC bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message