From owner-freebsd-arch@FreeBSD.ORG Sat Jun 2 17:28:00 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 D9FF91065677; Sat, 2 Jun 2012 17:28:00 +0000 (UTC) (envelope-from asmrookie@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 B96738FC25; Sat, 2 Jun 2012 17:27:59 +0000 (UTC) Received: by lbon10 with SMTP id n10so2985176lbo.13 for ; Sat, 02 Jun 2012 10:27:58 -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=Kt/O+PHHOpLhrbzodt5P7CT7LFTo8FnmSBDFttgcJ+Q=; b=ExKpAs160ZiDxSTWwl+bnQ6GlYzQUZii4nC6ISVvjIPZiUIGkFgx5RYvrZ/47oSwxX BcV6pTut9G8A06AG/px5pq0WaB1CozoIeiHs3B+w88+paZVX4XLt4DoOS3P/LC8t/UZW Ldjj57gN2hd3LkolH4tc13lkqR40JAH7Z1clmo9rGkDKOoDjfj5e2ega496ivOuWsRMI ubdBng/qjibr5I+7qhNTHxp7do8JYstDIrkUJNNPEEvlm7EA/dohuEOKTmtlbVpve6wV GSb4LCs24lC7TVft1T9MLOhH7X0DuIjNpQp4fBpdKk98iT0VmeAXW/Itgh4phR6qpoOa NpGw== MIME-Version: 1.0 Received: by 10.152.131.9 with SMTP id oi9mr6965358lab.39.1338658078575; Sat, 02 Jun 2012 10:27:58 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Sat, 2 Jun 2012 10:27:58 -0700 (PDT) In-Reply-To: <20120602171632.GC2358@deviant.kiev.zoral.com.ua> References: <20120601193522.GA2358@deviant.kiev.zoral.com.ua> <20120602164847.GB2358@deviant.kiev.zoral.com.ua> <20120602171632.GC2358@deviant.kiev.zoral.com.ua> Date: Sat, 2 Jun 2012 18:27:58 +0100 X-Google-Sender-Auth: 9_oCPwwfNLdlvGTKGIF6BSa9YTA Message-ID: From: Attilio Rao To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Alexander Kabaev , Alan Cox , Konstantin Belousov , Gianni , freebsd-arch@freebsd.org Subject: Re: Fwd: [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: Sat, 02 Jun 2012 17:28:00 -0000 2012/6/2 Konstantin Belousov : > On Sat, Jun 02, 2012 at 06:00:06PM +0100, Attilio Rao wrote: >> Sorry, resending with all the recipients in. >> >> Attilio >> >> >> ---------- Forwarded message ---------- >> From: Attilio Rao >> Date: 2012/6/2 >> Subject: Re: [RFC] Kernel shared variables >> To: Konstantin Belousov >> >> >> 2012/6/2 Konstantin Belousov : >> > On Sat, Jun 02, 2012 at 02:01:35PM +0100, Attilio Rao wrote: > [Tried to trim the text] > >> >> I think, he just wants to map in userland processes some pages from >> >> the static image of the kernel (packed together in a specific >> >> dataset). This imposes some non-trivial problem. The first thing is >> >> that the static image is not thought to have physical pages tied to >> >> it. The second is that he needs to make a clean design in order to let >> >> consumer of this mechanism to correctly locate informations they want >> >> within the shared page(s) and in the end read the correct values. >> > Right, exactly, and this is why I object to the "offsets" approach. >> > It basically moves us to the old times of the "jump tables" shared >> > libraries, that fortunately was never a case for FreeBSD even when >> > a.out was used. >> >> I'm objecting to this either. > My english is not good enough to understand this. Do you agree or disagree > with my statement that 'indexes' make it very hard to maintain ABI ? I agree with you. The offset approach just doesn't work clean on an ABI perspective. >> >> >> >> I have some reservations on both the implementation and the approach >> >> for retrieving datas from the page. >> >> In particular, I don't like that a new vm_object is allocated for this >> >> page. What I really would like would be: >> >> 1) very minimal implementation -- you just use >> >> pmap_enter()/pmap_remove() specifically when needed, separately, in >> >> fork(), execve(), etc. cases >> > Oh, this simply cannot work. >> >> And why? Assuming you provide a vm_page_t from an UMA zone just like >> fakepage do. Of course you cannot recycle for this purpose any page >> caming from vm_page_alloc(). > Due to pv_collect/pmap_pv_reclaim, the pte might be destroyed any time. > > Using hacks like mapping the page wired and then needing to hack > any VM space manipulation (fork/rfork/exec/exit/swapout/I possibly > missed several cases) just does not pay for it. Well my take was to map the page wired because of the nature of the workload too (static image -- present in memory -- wired page). [ trim ] >> The gettimeofday() implementation is a different story than what is asked here. > > But the goal is to have fast clocks, right ? What else is planned ? > > In fact, I think that if the whole goal is only fast clocks, then we > do not need any additional system mechanisms, since we can easily export > coefficients for rdtsc formula already. E.g. we can put it into elf auxv, > which is ugly but bearable. Not sure if there is anything else besides gettimeofday() that we want right now, in particular on global basis. I just mean to say that I don't think Giovanni put a lot of effort in correctness/robustness of gettimeofday userland implementation, so we should not judge that part of the patch too tightly. >> > Interesting question is how much shared the shared page needs be. >> > Obvious needs are shared between all same-ABI processes, but I can also >> > easily see a need for the per-process private information be present in >> > the 'private-shared' page. For silly but typical example, useful for >> > moronix-style benchmarks, see getpid(). >> >> Really the performance benefits of having fast getpid() is marginal if >> compared to heavilly used things like gettimeofday(). I cannot think >> of a per-process page implementing a fast syscall that can bring many >> perfomance advantages. > > This is completely true, but there may be other process-private data that > could benefit from the low access cost. I just do not know right now. I don't know either, thus I don't think there is a big urgence for per-process shared pages at all. Attilio -- Peace can only be achieved by understanding - A. Einstein