Date: Sat, 2 Jun 2012 18:27:58 +0100 From: Attilio Rao <attilio@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Alexander Kabaev <kan@freebsd.org>, Alan Cox <alc@rice.edu>, Konstantin Belousov <kib@freebsd.org>, Gianni <gianni@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Fwd: [RFC] Kernel shared variables Message-ID: <CAJ-FndCh77syp%2B860LaCbgQ6eiQAq_OMM98RxqxmCv%2BYKENXoA@mail.gmail.com> In-Reply-To: <20120602171632.GC2358@deviant.kiev.zoral.com.ua> References: <CACfq090r1tWhuDkxdSZ24fwafbVKU0yduu1yV2%2BoYo%2BwwT4ipA@mail.gmail.com> <20120601193522.GA2358@deviant.kiev.zoral.com.ua> <CAJ-FndC71=3Jo%2BBxQi==gCoLipBxj8X8XMBydjvrcKeGw%2BWOnA@mail.gmail.com> <20120602164847.GB2358@deviant.kiev.zoral.com.ua> <CAJ-FndAXFwuEspq%2BQeF0Hv1dr8JjREP=c=g3-abP=eoZ-D4hEg@mail.gmail.com> <CAJ-FndCpztSWyJo2hRVs5qu%2BvQOj9E1mPBhfVOxM_OC2eNac6A@mail.gmail.com> <20120602171632.GC2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/6/2 Konstantin Belousov <kostikbel@gmail.com>: > 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 <attilio@freebsd.org> >> Date: 2012/6/2 >> Subject: Re: [RFC] Kernel shared variables >> To: Konstantin Belousov <kostikbel@gmail.com> >> >> >> 2012/6/2 Konstantin Belousov <kostikbel@gmail.com>: >> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndCh77syp%2B860LaCbgQ6eiQAq_OMM98RxqxmCv%2BYKENXoA>