From owner-freebsd-hackers Thu Apr 4 10:11:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 88FFF37B439 for ; Thu, 4 Apr 2002 10:09:37 -0800 (PST) Received: from famine.cs.utah.edu (famine.cs.utah.edu [155.99.198.114]) by wrath.cs.utah.edu (8.11.6/8.11.6) with ESMTP id g34I9ab02775; Thu, 4 Apr 2002 11:09:36 -0700 (MST) Received: by famine.cs.utah.edu (Postfix, from userid 2373) id 13BFE23ACF; Thu, 4 Apr 2002 11:09:35 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by famine.cs.utah.edu (Postfix) with ESMTP id F38D0279D5; Thu, 4 Apr 2002 11:09:35 -0700 (MST) Date: Thu, 4 Apr 2002 11:09:35 -0700 (MST) From: John Regehr To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Linuxthreads on Linux vs FreeBSD performance question In-Reply-To: <3CAC036C.71DB41BB@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry, No need to use me as an excuse to vent your feelings about microbenchmarks vs. good benchmarks. I'm showing how to use a user-space instrumented application to measure scheduling behavior, not trying to make any claims about the relative merits of the operating systems in realistic conditions. These can and should be separate activities. Maybe I should include a few comments to this effect in the paper, in order to forestall reactions like yours? The last thing I want is to get into some sort of Linux vs. FreeBSD thing. Maybe I can prevent some of this by telling people that I used to hack the Windows 2000 scheduler! :) If it would help draw the flames now, while I can still do something about it (paper is due around Apr 15), I'd be happy to post a pointer to my paper. Technical comments follow. > Because you are attempting a comparative benchmark, I would > suspect that you are probably running a significantly > quiescent system (just the benchmark itself, and the code > being benchmarked, running). I expect that you have not > stopped "cron" (which runs once a second), nor have you > stopped other "system processes" which will end up in the > scheduling queue, No, I haven't stopped these activities. However, I'm only measuring the times for context switches between threads in my test application, so the things you mention are not throwing off the numbers. How is this accomplished? When other apps get to run during the test, this shows up as large gaps in the CPU time seen by my application, and these are thrown out as outliers -- they don't influence the statistics. The test is acutally quite robust in the sense that a fair amount of background activity doesn't throw off the numbers, but in this case more care has to be taken to throw out the outliers in a sensible way. I'm not running on an SMP either. > Right now, you are comparing apples and oranges. Sure, if: apples == expected time to execute the Linux context switch code when switching between two Linuxthreads, when the system load consists of 10 CPU-bound threads and very little other activity oranges == expected time to execute the FreeBSD context switch code when switching between two Linuxthreads, when the system load consists of 10 CPU-bound threads and very little other activity Thanks for the detailed answer, John Regehr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message