From owner-freebsd-arch@FreeBSD.ORG Fri Jun 1 22:23:43 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDEB01065670; Fri, 1 Jun 2012 22:23:43 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5158FC12; Fri, 1 Jun 2012 22:23:42 +0000 (UTC) Received: by qabg1 with SMTP id g1so692044qab.13 for ; Fri, 01 Jun 2012 15:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XEteMbH8tH0s92292qHmaUoLnGd0r/RCe99bVApaSaU=; b=Lu4IaRzeZdb76tjcTW3tulB2eQtIWCarzwabDYjO62yuvC+0Tw9MPrspwxwTtPKTwk ABcM/lO1QRx/BoaVMXx+5okHFgRT6VLVoEVPjut5Q1fTawFbiP4e2xbwPfShwcEp0oJw KJXm4PduB/9zvB8IqllSf7qItJoADLZM/f75+EzY3z61U/mTnwoB5uL6migsH1k1AU3Y Ev8k5kiboo633CZX3KlfPGT2K8Dxmn3CTD6HStoPaQPxtEbhdiH3oYSaJ2vOstOv74iD dofNu2JhW4FsAwCOOsqg+tAPPO3jOnIqc6+eXyoe/ErlvOvo93ZV3tv32leBlXzJFltH CNeA== MIME-Version: 1.0 Received: by 10.224.187.147 with SMTP id cw19mr6012337qab.47.1338589422333; Fri, 01 Jun 2012 15:23:42 -0700 (PDT) Received: by 10.229.160.20 with HTTP; Fri, 1 Jun 2012 15:23:42 -0700 (PDT) In-Reply-To: <20120602044306.S4049@besplex.bde.org> References: <20120602044306.S4049@besplex.bde.org> Date: Sat, 2 Jun 2012 00:23:42 +0200 Message-ID: From: Giovanni Trematerra To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Attilio Rao , alc@freebsd.org, Konstantin Belousov , Alexander Kabaev , freebsd-arch@freebsd.org Subject: Re: [RFC] Kernel shared variables 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: Fri, 01 Jun 2012 22:23:43 -0000 On Fri, Jun 1, 2012 at 11:21 PM, Bruce Evans wrote: > On Fri, 1 Jun 2012, Giovanni Trematerra wrote: > >> I'd like to discuss a way to provide a mechanism to share some read-only >> data between kernel and user space programs avoiding syscall overhead, >> implementing some them, such as gettimeofday(3) and time(3) as ordinary >> user space routine. > > > This is particularly unsuitable for implementing gettimeofday(), since fo= r > it to work you would need to use approximately 1 CPU spinning in the > kernel to update the time every microsecond. =A0For time(3), it only need= s > a relatively slow update. =A0For clock_gettime() with nansoeconds precisi= on, > it is even more unsuitable. =A0For clock_gettime() with precisions betwee= n > 1 second and 1 microseconds, it is intermediately unsuitable. > > It also requires some complications for locking/atomicity and coherency > (much the same as in the kernel. =A0Not just for times. =A0For times, the > kernel handles locking/atomicity fairly well, and coherency fairly badly. > Well, the primary intend of the patch is to provide a mechanism to share da= ta between kernel and user land without switching in kernel mode. Not to provi= de a complete re-implementation in user mode of all time stuff. > >> The patch at >> http://www.trematerra.net/patches/ksvar_experimental.patch >> >> is in a very experimental stage. It's just a proof-of-concept. >> Only works for an AMD64 kernel and only for 64-bit applications. >> The idea is to have all the variables that we want to share between kern= el >> and user space into one or more consecutive pages of memory that will be >> mapped read-only into every running process. At the start of the first >> shared page >> there'll be a table with as many entries as the number of the shared >> variables. >> Each entry is a 32-bit value that is the offset between the start of the >> shared >> page and the start of the variable in the page. The user space processes >> need >> to find out the map address of shared page and use the table to access t= o >> the >> shared variables. > > > On amd64, 2 32-bit values or 64-bit values with most bits 0 or 1 can be > packed/encoded into 1 64-bit value to give a certain atomicity without > locking. =A0The corresponding i386 packing into 1 32-bit value doesn't wo= rk > so well. These values are written just one time during a SYSINIT routine and are onl= y read by user processes. > >> ... > > >> Just as proof of concept I re-implemented gettimeofday(3) in user space. >> First of all I didn't remove the entry into the syscall.master, just >> renamed the >> sys_gettimeofday. I need it for the fallback path. >> In the kernel I introduced a struct wall_clock. >> >> +struct wall_clock >> +{ >> + =A0 =A0 =A0 struct timeval =A0tv; >> + =A0 =A0 =A0 struct timezone tz; >> +}; > > > This is much larger than 64 bits. =A0struct timezone is relatively > unimportant. > struct timeval is bloated on amd64 (128 bits), but can be packed into 64 > bits (works for a few hundred years). =A0On i386, it could be packed into > 20 bits for tv_usec and 12 bits for an offset for tv_sec. > Thanks a lot for your explanation. I think they will be precious as a refer= ence. Nonetheless I just wrote gettimeofday in that way just as proof-of-concept, just to show how things could be supposed to work, it didn't mean to be cor= rect. I think it was just unfortunate to have choose gettimeofday. I'm most interested in the VM things of the patch. -- Gianni