From owner-svn-src-all@FreeBSD.ORG Fri Jun 22 08:54:55 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1B1A106566B; Fri, 22 Jun 2012 08:54:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED55C8FC0C; Fri, 22 Jun 2012 08:54:54 +0000 (UTC) Received: by lbon10 with SMTP id n10so4038519lbo.13 for ; Fri, 22 Jun 2012 01:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BgGfywcsOZo6hMDfAJpkA/wkyhaIRvcoaHkAHCvLKj0=; b=XY9LCc1lsh8v8Jg33cTpeJcWZKZ5iAEwAywo0rqTkI25p3lTO2WEV68fPRhoUgILtP 7FUyfSKdRxFTSAhKZ07g7t6hfi0Gktv1FJGWG8rC4kNnYVor8ejJFMFURH3MJGjnjPLN 9gbOs08M41q7jibSocJxFOXWejLzZ2/OodPo2D14U2cYYGCzTkQ20JSle+xRPRzIVICk UqMbkMzdYTLV+0zB5qRmMidecQ++EivZppBlocbjXABf7+wAGdiggmZ4JhNQyqM13rLh gnx2A1FXQMAYIGdOTgIhMutDVYZBFYU5Wn7XldVV3hlpQoiWQJZrAJCOWk2rhKbUiEOT 6DmA== Received: by 10.152.148.169 with SMTP id tt9mr1270249lab.49.1340355293866; Fri, 22 Jun 2012 01:54:53 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id hi14sm51186795lab.4.2012.06.22.01.54.51 (version=SSLv3 cipher=OTHER); Fri, 22 Jun 2012 01:54:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FE432C4.7000608@FreeBSD.org> Date: Fri, 22 Jun 2012 11:54:28 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Konstantin Belousov References: <201206220706.q5M76fbO062751@svn.freebsd.org> <4FE42812.3050807@FreeBSD.org> <20120622082502.GB2337@deviant.kiev.zoral.com.ua> In-Reply-To: <20120622082502.GB2337@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r237433 - in head/sys: amd64/include arm/include conf i386/include ia64/include kern mips/include pc98/include powerpc/include sparc64/include sys x86/include x86/x86 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 08:54:56 -0000 On 22.06.2012 11:25, Konstantin Belousov wrote: > On Fri, Jun 22, 2012 at 11:08:50AM +0300, Alexander Motin wrote: >> On 06/22/12 10:06, Konstantin Belousov wrote: >>> Author: kib >>> Date: Fri Jun 22 07:06:40 2012 >>> New Revision: 237433 >>> URL: http://svn.freebsd.org/changeset/base/237433 >>> >>> Log: >>> Implement mechanism to export some kernel timekeeping data to >>> usermode, using shared page. The structures and functions have vdso >>> prefix, to indicate the intended location of the code in some future. >>> >>> The versioned per-algorithm data is exported in the format of struct >>> vdso_timehands, which mostly repeats the content of in-kernel struct >>> timehands. Usermode reading of the structure can be lockless. >>> Compatibility export for 32bit processes on 64bit host is also >>> provided. Kernel also provides usermode with indication about >>> currently used timecounter, so that libc can fall back to syscall if >>> configured timecounter is unknown to usermode code. >>> >>> The shared data updates are initiated both from the tc_windup(), where >>> a fast task is queued to do the update, and from sysctl handlers which >>> change timecounter. A manual override switch >>> kern.timecounter.fast_gettime allows to turn off the mechanism. >>> >>> Only x86 architectures export the real algorithm data, and there, only >>> for tsc timecounter. HPET counters page could be exported as well, but >>> I prefer to not further glue the kernel and libc ABI there until >>> proper vdso-based solution is developed. >>> >>> Minimal stubs neccessary for non-x86 architectures to still compile >>> are provided. >>> >>> Discussed with: bde >>> Reviewed by: jhb >>> Tested by: flo >>> MFC after: 1 month >> >> >>> @@ -1360,6 +1367,7 @@ tc_windup(void) >>> #endif >>> >>> timehands = th; >>> + taskqueue_enqueue_fast(taskqueue_fast,&tc_windup_push_vdso_task); >>> } >>> >>> /* Report or change the active timecounter hardware. */ >> >> This taskqueue_enqueue_fast() will schedule extra thread to run each >> time hardclock() fires. One thread may be not a big problem, but >> together with callout swi and possible other threads woken up there it >> will wake up several other CPU cores from sleep just to put them back in >> few microseconds. Now davide@ and me are trying to fix that by avoiding >> callout SWI use for simple tasks. Please, let's not create another >> problem same time. > > The patch was public for quite a time. If you have some comments about > it, it would be much more productive to let me know about them before > the commit, not after. I'm sorry, I haven't seen it. My mad. > Anyway, what is your proposal for 'let's not create another problem > same time' part of the message ? It was discussed, as a possibility, > to have permanent mapping for the shared page in the KVA and to perform > lock-less update of the struct vdso_timehands directly from hardclock > handler. My opinion was that amount of work added by tc_windup > eventhandler is not trivial, so it is better to be postponed to > less critical context. It also slightly more safe to not perform > lockless update for vdso_timehands, since otherwise module load which > register exec handler could cause transient gettimeofday() failure > in usermode. > > This might boil down to the fact that tc_windup function is called > too often, in fact. Also, packing execution of tc_windup eventhandler > together with the clock swi is fine from my POV. I have nothing against using shared pages. On UP system I would probably have not so much against several threads. But on SMP system it will cause at least one, but in many cases two extra CPUs to be woken up. There are two or more threads to run on hardclock(): this taskqueue, callout swi and some thread(s) woken from callouts. Scheduler has no idea how heavy they are. So it will try to move each of them to separate idle CPU. Does the amount of work done in event handlers worth extra Watts consumed by rapidly waking CPUs? As quite rare person running FreeBSD on laptop, I am not sure. I am not sure even that on desktop/server this won't kill all benefit of fast clocks by limiting TurboBoost. -- Alexander Motin