Date: Sat, 30 Mar 2002 08:30:48 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-smp@FreeBSD.ORG Subject: Re: Syscall contention tests return, userret() bugs/issues. Message-ID: <Pine.NEB.3.96L.1020330082409.73912V-100000@fledge.watson.org> In-Reply-To: <11416.1017476076@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 30 Mar 2002, Poul-Henning Kamp wrote: > 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... For builds, I would think that the really relevant test case might be a zero-byte loop-back pipe write / read pair. This would still be a single process, but would optimize handling of a system call that appears to be highly relevant to the build process. At least last I heard, Peter had identified pipe operations (pre-alfredpipe) as being one of the big issues in a parallel build due to make's use of pipes for IPC in frequent and small intervals. I don't know if he's run the numbers since then -- one benefit to moving the Giant grabbing to inside #ifdef ktrace would be that we might be able to do better benchmarking of the pipe case, which Alfred has told me hasn't improved much (possibly for this reason), if only in experimental code. That should demonstrate the performance impact of the fine-graind locking that we believe should be there. That said, if getuid as the example micro-benchmark can be demonstrated to causally affect optimize the macro-benchmark, then the selection of micro-benchmark by implementation facility sounds reasonable to me. :-) Matt's original post used 1-process and 2-process build pairs in a macro-benchmark style, so I imagine all is set on that front, since he'd demonstrated that related contention existed in that path, and done experimentation instrumentation that noted a similar performance impact in the macro-benchmark from the micro-benchmark. Before commit time comes, clearly the macros need to run and demonstrate happiness, of couse. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020330082409.73912V-100000>