From owner-freebsd-smp Sat Mar 30 0:16:20 2002 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id B147437B4AB; Sat, 30 Mar 2002 00:15:08 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2U8Eae7011417; Sat, 30 Mar 2002 09:14:36 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: John Baldwin , freebsd-smp@FreeBSD.ORG Subject: Re: Syscall contention tests return, userret() bugs/issues. In-Reply-To: Your message of "Fri, 29 Mar 2002 14:07:15 PST." <200203292207.g2TM7Fi67491@apollo.backplane.com> Date: Sat, 30 Mar 2002 09:14:36 +0100 Message-ID: <11416.1017476076@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <200203292207.g2TM7Fi67491@apollo.backplane.com>, Matthew Dillon wri > And do a compative syscall rate test on a two-cpu system running > two getuid() processes, this happens: > > 1 process 2 processes > w/PCPU: 1004000 1000000 > w/++cnt.v_syscall: 1004000 853000 But is this a relevant test-case to optimize for ? We are trying to eliminate all often used trivial syscalls need to get into the kernel in the first place, and for non-trivial syscalls it doesn't matter a hoot how that increment is done... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message