From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 08:56:56 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 174BE1065673 for ; Mon, 11 Jun 2012 08:56:56 +0000 (UTC) (envelope-from rwatson@freeBSd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E4E668FC18 for ; Mon, 11 Jun 2012 08:56:55 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2B43846B0A; Mon, 11 Jun 2012 04:56:55 -0400 (EDT) Date: Mon, 11 Jun 2012 09:56:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Konstantin Belousov In-Reply-To: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> Message-ID: References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 08:56:56 -0000 On Wed, 6 Jun 2012, Konstantin Belousov wrote: > The whole struct vdso_timekeep is versioned, as well as individual struct > vdso_timehands, which should allow to implement future algorithms without > breaking binary compatibility. The code is structured to eventually move > __vdso_* functions out of libc into VDSO, if it ever materialize. This > desire explains vdso prefix and header file names. > > I implemented and tested the userspace timecounter on amd64, both for 64 and > 32 bit binaries, it would probably work for i386 too. Other architecture > maintainers are welcome to add neccessary support there. You need to provide > machine/vdso.h header with definitions of VDSO_TIMEHANDS_MD fields for > struct vdso_timehands, which should provide information for userspace to > implement fast tc_get_timecount(). The fields are filled in per-arch > cpu_fill_vdso_timehands(9) function. If your architecture support 32bit > compat, there are cpu_fill_vdso_timehands32(9) and VDSO_TIMEHANDS_MD32 to > code as well. After that, the lib/libc//sys/__vdso_gettc.c should > contain an implemention of __vdso_gettc() function, exact analogue of > tc_get_timecount(). Hi Kostik: I'm glad to see someone is finally grappling with this issue. I could never entirely decide how I felt about the Linux VSDO mechanism, but having some solution here is actually quite important. A few thoughts that you might comment on: 1) It would be nice if we linked any (future) notion of VDSO to the same mechanism we use for ELF branding/ABI emulation -- you conceivably want to support it not just for native ABI and perhaps 32-bit compat ABIs, but also the Linux ABI, alternative userspace ABIs (vis o32 on an n64 MIPS kernel), and so on. 2) Once the VDSO mechanism is there, you get into feature creep space, and looking at how Linux handles pluggable system call mechanisms for the C library is actually interesting. 3) For the purposes of adaptive mutexes in userspace, it really would be quite nice to know whether remote threads are running or not, in the same way that cheap access to remote thread run state in the kernel makes for much more efficient adaptive spinning. I wonder if we could use this mechanism for that purpose as well. I guess for now, at least, you're using a single global page, but in the future, per-process pages might be quite beneficial. Robert From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 09:18:17 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F4BE106566B; Mon, 11 Jun 2012 09:18:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1FB8FC1A; Mon, 11 Jun 2012 09:18:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5B9ICrq015854; Mon, 11 Jun 2012 12:18:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5B9IB5N002415; Mon, 11 Jun 2012 12:18:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5B9IBEY002414; Mon, 11 Jun 2012 12:18:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Jun 2012 12:18:11 +0300 From: Konstantin Belousov To: Robert Watson Message-ID: <20120611091811.GA2337@deviant.kiev.zoral.com.ua> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:18:17 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2012 at 09:56:54AM +0100, Robert Watson wrote: > On Wed, 6 Jun 2012, Konstantin Belousov wrote: >=20 > >The whole struct vdso_timekeep is versioned, as well as individual struc= t=20 > >vdso_timehands, which should allow to implement future algorithms withou= t=20 > >breaking binary compatibility. The code is structured to eventually mov= e=20 > >__vdso_* functions out of libc into VDSO, if it ever materialize. This= =20 > >desire explains vdso prefix and header file names. > > > >I implemented and tested the userspace timecounter on amd64, both for 64= =20 > >and 32 bit binaries, it would probably work for i386 too. Other=20 > >architecture maintainers are welcome to add neccessary support there. Yo= u=20 > >need to provide machine/vdso.h header with definitions of=20 > >VDSO_TIMEHANDS_MD fields for struct vdso_timehands, which should provide= =20 > >information for userspace to implement fast tc_get_timecount(). The fiel= ds=20 > >are filled in per-arch cpu_fill_vdso_timehands(9) function. If your=20 > >architecture support 32bit compat, there are cpu_fill_vdso_timehands32(9= )=20 > >and VDSO_TIMEHANDS_MD32 to code as well. After that, the=20 > >lib/libc//sys/__vdso_gettc.c should contain an implemention of=20 > >__vdso_gettc() function, exact analogue of tc_get_timecount(). >=20 > Hi Kostik: >=20 > I'm glad to see someone is finally grappling with this issue. I could=20 =46rom the real-world tests, it seems that e.g. mysql does not notice any difference with the faster (4-7x) gettimeofday() and clock_gettime() implementations. > never entirely decide how I felt about the Linux VSDO mechanism, but havi= ng=20 > some solution here is actually quite important. A few thoughts that you= =20 > might comment on: >=20 > 1) It would be nice if we linked any (future) notion of VDSO to the same > mechanism we use for ELF branding/ABI emulation -- you conceivably wan= t=20 > to > support it not just for native ABI and perhaps 32-bit compat ABIs, but= =20 > also > the Linux ABI, alternative userspace ABIs (vis o32 on an n64 MIPS=20 > kernel), > and so on. This is solved almost automatically with any sensible VDSO implementation, since VDSO _must_ be per-ABI. You simply cannot use amd64 VDSO in 32bit process. Please note that even the current shared page mechanism is already per-ABI, since it is attached to struct sysentvec instance. It just so happen that I found convenient and less resoirce-wasteful to reuse the same page for both 32bit and 64bit on amd64. For VDSO, it definitely should be separated (which is trivial). VDSO for Linux is required to have Linux/amd64 emulator running. At least I was told so by Chagin. >=20 > 2) Once the VDSO mechanism is there, you get into feature creep space, and > looking at how Linux handles pluggable system call mechanisms for the C > library is actually interesting. Yes, there is a possibility. But really I think that we should left i386 on the pasture. Do we really care about 0.5% (?) of the speed for 32 bit binaries ? Main benefits from VDSO is due to improved toolchain support (dwarf unwinding for signal trampolines) and specific operation optimizations, like gettimeofday(), which is performed without the need to keep kernel ABI intact, IMO. As an example, I saw that Linux could export HPET registers page r/o on machines where rdtsc is unusable. Due to VDSO, this is transparent to libc. I preferred not to port HPET timers into usermode for now exactly because libc should become aware of them. >=20 > 3) For the purposes of adaptive mutexes in userspace, it really would be= =20 > quite > nice to know whether remote threads are running or not, in the same way > that cheap access to remote thread run state in the kernel makes for m= uch > more efficient adaptive spinning. I wonder if we could use this=20 > mechanism > for that purpose as well. I guess for now, at least, you're using a= =20 > single > global page, but in the future, per-process pages might be quite > beneficial. The per-process page looks almost undoable. I think that what could be made working, although with some hacks, is per-CPU page, and the page content update on context switch. This could benefit trivial system calls like getpid(), getppid() and others, but obviously cause increased context switch latency. Per-CPU page would then solve the proposal of having an indicator of other threads running. I am not sure how much do we care of the potential information leak there. --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/Vt9MACgkQC3+MBN1Mb4jWuQCgghMXFCoEjGSg6ZE/7xL5C9an H84An1rmZwY647w0aU2d3g1uwCWQ3Fql =i58I -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 09:22:34 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A73C81065672 for ; Mon, 11 Jun 2012 09:22:34 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2098FC23 for ; Mon, 11 Jun 2012 09:22:34 +0000 (UTC) Received: from [192.168.2.111] (host86-182-204-28.range86-182.btcentralplus.com [86.182.204.28]) by cyrus.watson.org (Postfix) with ESMTPSA id BA57646B0D; Mon, 11 Jun 2012 05:22:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20120611091811.GA2337@deviant.kiev.zoral.com.ua> Date: Mon, 11 Jun 2012 10:22:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <20120611091811.GA2337@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1257) Cc: arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:22:34 -0000 On 11 Jun 2012, at 10:18, Konstantin Belousov wrote: >> 3) For the purposes of adaptive mutexes in userspace, it really would = be=20 >> quite >> nice to know whether remote threads are running or not, in the same = way >> that cheap access to remote thread run state in the kernel makes = for much >> more efficient adaptive spinning. I wonder if we could use this=20 >> mechanism >> for that purpose as well. I guess for now, at least, you're using = a=20 >> single >> global page, but in the future, per-process pages might be quite >> beneficial. >=20 > The per-process page looks almost undoable. I think that what could be > made working, although with some hacks, is per-CPU page, and the page > content update on context switch. This could benefit trivial system = calls > like getpid(), getppid() and others, but obviously cause increased = context > switch latency. >=20 > Per-CPU page would then solve the proposal of having an indicator of > other threads running. I am not sure how much do we care of the = potential > information leak there. FYI, the FreeBSD/MIPS kernel already makes use of an MD per-thread page = using a reserved TLB entry switched on each kernel context switch. = Interestingly, this model effectively conflicts (semantically) with the = higher-level MI per-CPU mechanism. It would be nice to unify across the = layers within the kernel, even if not all the way to userspace. Robert= From owner-freebsd-arch@FreeBSD.ORG Mon Jun 11 10:49:21 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28247106566B; Mon, 11 Jun 2012 10:49:21 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D9DEB8FC0A; Mon, 11 Jun 2012 10:49:19 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2036F7300A; Mon, 11 Jun 2012 13:08:04 +0200 (CEST) Date: Mon, 11 Jun 2012 13:08:04 +0200 From: Luigi Rizzo To: "Robert N. M. Watson" , Konstantin Belousov , arch@freebsd.org Message-ID: <20120611110804.GA8085@onelab2.iet.unipi.it> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <20120611091811.GA2337@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Subject: scheduler/context switch cost (Re: Fast gettimeofday(2) and clock_gettime(2)) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 10:49:21 -0000 On Mon, Jun 11, 2012 at 10:22:31AM +0100, Robert N. M. Watson wrote: > > On 11 Jun 2012, at 10:18, Konstantin Belousov wrote: ... > > The per-process page looks almost undoable. I think that what could be > > made working, although with some hacks, is per-CPU page, and the page > > content update on context switch. This could benefit trivial system calls > > like getpid(), getppid() and others, but obviously cause increased context > > switch latency. > > > > Per-CPU page would then solve the proposal of having an indicator of > > other threads running. I am not sure how much do we care of the potential > > information leak there. > > FYI, the FreeBSD/MIPS kernel already makes use of an MD per-thread page using a reserved TLB entry switched on each kernel context switch. Interestingly, this model effectively conflicts (semantically) with the higher-level MI per-CPU mechanism. It would be nice to unify across the layers within the kernel, even if not all the way to userspace. Since you mention context switch times: when doing latency tests with netmap/VALE i notice horrible RTT values (relatively speaking -- i am talking about 6us for VALE, and perhaps 12-14us for netmap) which are most likely responsibility of slow scheduler and the way we implement poll() in the kernel. I still need to do some more measurements but for instance, on ixgbe the delay between interrupt notification (the fast handler, if you like) and the start of the interrupt thread is never below 2500 ticks (on a 2.93 GHz machine) and usually around 6000-8000 ticks. This really seems high, and i wonder if it is an inherent problem or it is a result of some implementation or design oversight. A poll() that may need to block (thus needlessly calling selrecord, then cleaned up when it finds a ready descriptor afterwards) seems similarly slow (in the order of a couple of microseconds, if i remember correctly). Do people have experience on the performance of the scheduler etc. and ideas on where to look to improve that ? cheers luigi From owner-freebsd-arch@FreeBSD.ORG Tue Jun 12 01:52:53 2012 Return-Path: Delivered-To: arch@freeBSd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1AFD1065673; Tue, 12 Jun 2012 01:52:52 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D31E98FC19; Tue, 12 Jun 2012 01:52:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q5C1qojR007844; Tue, 12 Jun 2012 01:52:51 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4FD6A0F2.4010305@gmail.com> Date: Tue, 12 Jun 2012 09:52:50 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Robert Watson References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@freeBSd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freeBSd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 01:52:53 -0000 On 2012/6/11 16:56, Robert Watson wrote: > On Wed, 6 Jun 2012, Konstantin Belousov wrote: > >> The whole struct vdso_timekeep is versioned, as well as individual >> struct vdso_timehands, which should allow to implement future >> algorithms without breaking binary compatibility. The code is >> structured to eventually move __vdso_* functions out of libc into >> VDSO, if it ever materialize. This desire explains vdso prefix and >> header file names. >> >> I implemented and tested the userspace timecounter on amd64, both for >> 64 and 32 bit binaries, it would probably work for i386 too. Other >> architecture maintainers are welcome to add neccessary support there. >> You need to provide machine/vdso.h header with definitions of >> VDSO_TIMEHANDS_MD fields for struct vdso_timehands, which should >> provide information for userspace to implement fast >> tc_get_timecount(). The fields are filled in per-arch >> cpu_fill_vdso_timehands(9) function. If your architecture support >> 32bit compat, there are cpu_fill_vdso_timehands32(9) and >> VDSO_TIMEHANDS_MD32 to code as well. After that, the >> lib/libc//sys/__vdso_gettc.c should contain an implemention of >> __vdso_gettc() function, exact analogue of tc_get_timecount(). > > Hi Kostik: > > I'm glad to see someone is finally grappling with this issue. I could > never entirely decide how I felt about the Linux VSDO mechanism, but > having some solution here is actually quite important. A few thoughts > that you might comment on: > > 1) It would be nice if we linked any (future) notion of VDSO to the same > mechanism we use for ELF branding/ABI emulation -- you conceivably > want to > support it not just for native ABI and perhaps 32-bit compat ABIs, > but also > the Linux ABI, alternative userspace ABIs (vis o32 on an n64 MIPS > kernel), > and so on. > > 2) Once the VDSO mechanism is there, you get into feature creep space, > and > looking at how Linux handles pluggable system call mechanisms for > the C > library is actually interesting. > > 3) For the purposes of adaptive mutexes in userspace, it really would > be quite > nice to know whether remote threads are running or not, in the same > way > that cheap access to remote thread run state in the kernel makes > for much > more efficient adaptive spinning. I wonder if we could use this > mechanism > for that purpose as well. I guess for now, at least, you're using > a single > global page, but in the future, per-process pages might be quite > beneficial. > Solaris uses per-thread page shared between kernel and userland, their schedctl() interface is designed for this purpose, not only you can know if a thread is running, but also userland can tell kernel to not preempt the current thread while is in critical section, for example, it is doing adaptive spin, set a no_preempt bit to let kernel delay for a few of ticks before it preempts the thread immediately. I even have an earlier patch: http://people.freebsd.org/~davidxu/schedctl/ However I don't know if you can get real-world advantage if you really implemented this feature because this might increase cache-line sharing. > Robert From owner-freebsd-arch@FreeBSD.ORG Sat Jun 16 16:55:36 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB77A1065672; Sat, 16 Jun 2012 16:55:36 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 803488FC14; Sat, 16 Jun 2012 16:55:36 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3462015ghb.13 for ; Sat, 16 Jun 2012 09:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jfFS1fgkmljtHnIPDJf2Jluzug/q3ATUoi3aP6HLsjA=; b=PAprKYtH/n9esZ4wUsq2u8yl2yUvzvNDctzxahSFwJJmffkfgkaVIK/Db7SmZUzIsU SRhqaZVgrkImjNY+y6uiD4hgQNx2ssPRNmQFOlP4ps0eUSbVM15llA58O4RAMe6Z4yq/ M4V3gNJQreKNzsdapB/6PO06w80l+dWzUyn/xbAMoov0iygTxdqOn63ppccrAgJ8+9dw aAnWf9S002G4G23TDDSpEq30EITB82MWDG5x4HTE2lolF/0BOQVIE5HKDN2A0N7k8Obf 0RLODOv0856vJVEbCG9eMBIZomA9eJklp+7R43ZaeeTG+yVBz5KPvSMyugtfsrgbHTdN f+6g== MIME-Version: 1.0 Received: by 10.50.222.170 with SMTP id qn10mr4870423igc.45.1339865735601; Sat, 16 Jun 2012 09:55:35 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.42.117.196 with HTTP; Sat, 16 Jun 2012 09:55:35 -0700 (PDT) In-Reply-To: <20120526235510.GB90668@ithaqua.etoilebsd.net> References: <20120526235510.GB90668@ithaqua.etoilebsd.net> Date: Sat, 16 Jun 2012 18:55:35 +0200 X-Google-Sender-Auth: AD_gzFe66Enul6lzpR19gELx_8U Message-ID: From: Robert Millan To: Baptiste Daroussin Content-Type: multipart/mixed; boundary=14dae9341111379e8e04c299cdf0 Cc: arch@freebsd.org Subject: Re: switch tounconditionnal boostrapping while to build the tree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 16:55:37 -0000 --14dae9341111379e8e04c299cdf0 Content-Type: text/plain; charset=UTF-8 2012/5/27 Baptiste Daroussin : > so if no one care I'll remove the condition to boostrap at least yacc(1) and > lex(1) on current, 9, 8 and 7. While we are at it, would you mind if ${YACC} was set to "byacc" on current? This would make sys.mk re-usable on systems where "yacc" is a symlink to bison (e.g. Debian). -- Robert Millan --14dae9341111379e8e04c299cdf0 Content-Type: application/octet-stream; name="byacc.diff" Content-Disposition: attachment; filename="byacc.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h3ixcvom0 SW5kZXg6IHNoYXJlL21rL3N5cy5tawo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzaGFyZS9tay9zeXMubWsJKHJl dmlzaW9uIDIzNzE1NykKKysrIHNoYXJlL21rL3N5cy5tawkod29ya2luZyBjb3B5KQpAQCAtMTM4 LDcgKzEzOCw3IEBACiAKIFNIRUxMCQk/PQlzaAogCi1ZQUNDCQk/PQl5YWNjCitZQUNDCQk/PQli eWFjYwogLmlmIGRlZmluZWQoJVBPU0lYKQogWUZMQUdTCQk/PQogLmVsc2UK --14dae9341111379e8e04c299cdf0-- From owner-freebsd-arch@FreeBSD.ORG Sat Jun 16 20:39:37 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69A96106566C; Sat, 16 Jun 2012 20:39:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D46F08FC0C; Sat, 16 Jun 2012 20:39:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5GKdNAr096806; Sat, 16 Jun 2012 23:39:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5GKdNbs068233; Sat, 16 Jun 2012 23:39:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5GKdNQb068232; Sat, 16 Jun 2012 23:39:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 16 Jun 2012 23:39:22 +0300 From: Konstantin Belousov To: arch@freebsd.org Message-ID: <20120616203922.GV2337@deviant.kiev.zoral.com.ua> References: <20120612215319.GR2337@deviant.kiev.zoral.com.ua> <201206131537.34738.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RI0j69zTdciYrvy/" Content-Disposition: inline In-Reply-To: <201206131537.34738.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: flo@freebsd.org, bde@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 20:39:37 -0000 --RI0j69zTdciYrvy/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The latest version of the patch is at http://people.freebsd.org/~kib/misc/moronix.6.patch The patch was extensively discussed with Bruce, reviewed by John and performance-tested by Florian. I consider it ready for commit. Patch enables shared page on i386, since it now has a use on this architecture as well. For non-x86, a placeholder is implemented to allow the architectures to compile. I cannot test them, and I would be glad to get confirmations that gettimeofday() is not broken on them. I looked over some non-x86 architectures, in particular, mips, powerpc and sparc, which have facilities similar to tsc. I definitely will help for architecture maintainers to implement usermode gettimeofday(). Unless somebody raise valid objections, I plan to commit this next week. --RI0j69zTdciYrvy/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/c7voACgkQC3+MBN1Mb4iDSgCg6ZHZli4DehQT+je168ztjxdy U+sAoNn7YjndjpUl8337eBKAhsGVZklu =bHrb -----END PGP SIGNATURE----- --RI0j69zTdciYrvy/--