Date: Mon, 4 Jun 2012 10:53:51 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Gianni <gianni@freebsd.org>, Alan Cox <alc@rice.edu>, Alexander Kabaev <kan@freebsd.org>, Attilio Rao <attilio@freebsd.org>, Konstantin Belousov <kib@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: Fwd: [RFC] Kernel shared variables Message-ID: <201206041053.51802.jhb@freebsd.org> In-Reply-To: <CAJ-FndCh77syp%2B860LaCbgQ6eiQAq_OMM98RxqxmCv%2BYKENXoA@mail.gmail.com> References: <CACfq090r1tWhuDkxdSZ24fwafbVKU0yduu1yV2%2BoYo%2BwwT4ipA@mail.gmail.com> <20120602171632.GC2358@deviant.kiev.zoral.com.ua> <CAJ-FndCh77syp%2B860LaCbgQ6eiQAq_OMM98RxqxmCv%2BYKENXoA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, June 02, 2012 1:27:58 pm Attilio Rao wrote: > >> 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. I think this is an important question actually. Is there anything that really needs to be here besides gettimeofday()? I mean, is there any real-world application that needs to call getpid() or getppid() a bunch of times? Things that are static like that the application can easily cache (and should if it actually needs it). gettimeofday() is different because it is dynamic. > >> > 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. I can't think of anything useful. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206041053.51802.jhb>