From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 23:54:48 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 889DF16A41F; Fri, 28 Oct 2005 23:54:48 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA38843D46; Fri, 28 Oct 2005 23:54:47 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.96] ([70.68.0.213]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j9SNsZ3e020705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Oct 2005 01:54:36 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4362BA38.1090603@portaone.com> Date: Fri, 28 Oct 2005 16:54:32 -0700 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <32412.1130505646@critter.freebsd.dk> In-Reply-To: <32412.1130505646@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.2/1149/Thu Oct 27 22:20:09 2005 on www.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.0 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on www.portaone.com Cc: Pertti Kosunen , Robert Watson , David Xu , "Yuriy N. Shkandybin" , current@FreeBSD.ORG Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 23:54:48 -0000 Poul-Henning Kamp wrote: > In message <20051028140556.W20147@fledge.watson.org>, Robert Watson writes: > >>On Fri, 28 Oct 2005, David Xu wrote: >> >> >>>Poul-Henning Kamp wrote: >>> >>>>In message <4361FDBE.7000500@freebsd.org>, David Xu writes: >>>> >>>>the correct way to optimize this would be to add a time(2) systemcall >>>>which returns the value of the kernel global time_second. >>> >>>Can we make a page in kernel address space which is readable my user >>>code? put the variable in the page, I know read an integer is atomic-op, >>>needn't lock, so syscall is not needed. >> >>This approach has a lot of merit, as we can also potentially export other >>information there (such as kernel preferences for system call mechanisms). > > > Yes, there are many advantages to this approach, but we need a solution > to the API versioning problem before we head that way. > > For anyone wanting to look at this, three are a number of nasties > to remember: > > 1. How does userland get hold of the page ? Does it open a magic > device ? Use a magic syscall ? Or does all processes just get > the page by default ? > > 2. Where in the address space do we put it ? > > 3. Layout and alignment issues. Remember that things change size > over time. (Version numbers for each element ?) And that cross- > arch support is desirable (32bit i386 binaries on 64bit amd64 arch) > > 4. Do guarantee a syscall fallback for all facilities if there is version > skew, or do we abort the program ? > > 5. Do we want a global system page and a per process page while we > are at it. There is plenty of stuff we could put in the per-proc > page: pid, ppid, resource usage, proctitle etc. You can solve most of those issues by exporting from kernel to userland not only page(s) with actual data, but also page(s) with code to handle that data. Then you can turn syscalls implementation in libc into plain function calls to addresses in that code page(s). This approach can potentially have other interesting applications, for example it will be possible to use processor-specific syscalls instructions without recompiling userland, move some of the ABI code into userland (i.e. freebsd32 layer on amd64) etc. -Maxim