From owner-freebsd-arch@FreeBSD.ORG Wed Dec 26 19:24:57 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA8BE7ED; Wed, 26 Dec 2012 19:24:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mx1.freebsd.org (Postfix) with ESMTP id ED0EA8FC0A; Wed, 26 Dec 2012 19:24:56 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm6so7315626wib.3 for ; Wed, 26 Dec 2012 11:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Obqzhm1447Fw6lGkhMWiQjoVxYq6ZTwnx1VAYzddfYY=; b=b9Hfc7QrgMjroL/GXkG5LmwH0K69R2nfIbMOrPcBB0AiaaBMbqn0AVnkN0Ml3u47Aj bdAT+Eb2BF0gP6TEHMzzic7ITalnN0Fx8Am1bEm49jgHSS6FkaWF9/fl89Ap9a8CnQet ga8PLePG82cuNBQiJWs8/IwP3bTQoWqIn+stwdcgAVGXOE1Cr+LEEfz1i/v6qXxU3bX+ 32z2/pzTRWomQVmr+vpObw7OpV3YvPP2W7mELl1nJXqPBLEHEjAkpkpl+e90ELt4CwHj yo4hFKIHl5AGhaqodUm/kwGQB+m5gWfzNzwlwLM6+ZnWPPyDVT1GCH/9pyZbpzW7Is9o ncXA== X-Received: by 10.180.90.106 with SMTP id bv10mr43765614wib.12.1356549889109; Wed, 26 Dec 2012 11:24:49 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([91.198.175.1]) by mx.google.com with ESMTPS id g2sm45411030wiy.0.2012.12.26.11.24.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Dec 2012 11:24:48 -0800 (PST) Sender: Alexander Motin Message-ID: <50DB4EFE.2020600@FreeBSD.org> Date: Wed, 26 Dec 2012 21:24:46 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marius Strobl Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> In-Reply-To: <20121225232126.GA47692@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 19:24:57 -0000 On 26.12.2012 01:21, Marius Strobl wrote: > On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote: >> Experiments with dummynet shown ineffective support for very short >> tick-based callouts. New version fixes that, allowing to get as many >> tick-based callout events as hz value permits, while still be able to >> aggregate events and generating minimum of interrupts. >> >> Also this version modifies system load average calculation to fix some >> cases existing in HEAD and 9 branches, that could be fixed with new >> direct callout functionality. >> >> http://people.freebsd.org/~mav/calloutng_12_17.patch >> >> With several important changes made last time I am going to delay commit >> to HEAD for another week to do more testing. Comments and new test cases >> are welcome. Thanks for staying tuned and commenting. > > FYI, I gave both calloutng_12_15_1.patch and calloutng_12_17.patch a > try on sparc64 and it at least survives a buildworld there. However, > with the patched kernels, buildworld times seem to increase slightly but > reproducible by 1-2% (I only did four runs but typically buildworld > times are rather stable and don't vary more than a minute for the > same kernel and source here). Is this an expected trade-off (system > time as such doesn't seem to increase)? I don't think build process uses significant number of callouts to affect results directly. I think this additional time could be result of the deeper next event look up, done by the new code, that is practically useless for sparc64, which effectively has no cpu_idle() routine. It wouldn't affect system time and wouldn't show up in any statistics (except PMC or something alike) because it is executed inside timer hardware interrupt handler. If my guess is right, that is a part that probably still could be optimized. I'll look on it. Thanks. > Is there anything specific to test? Since the most of code is MI, for sparc64 I would mostly look on related MD parts (eventtimers and timecounters) to make sure they are working reliably in more stressful conditions. I still have some worries about possible deadlock on hardware where IPIs are used to fetch present time from other CPU. Here is small tool we are using for test correctness and performance of different user-level APIs: http://people.freebsd.org/~mav/testsleep.c -- Alexander Motin