Date: Tue, 5 Jun 2012 01:12:02 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Giovanni Trematerra <gianni@freebsd.org> Cc: Alan Cox <alc@rice.edu>, Alexander Kabaev <kan@freebsd.org>, Attilio Rao <attilio@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Fwd: [RFC] Kernel shared variables Message-ID: <20120604221202.GG85127@deviant.kiev.zoral.com.ua> In-Reply-To: <CACfq0933BwaverZinGvKtErPvdZp%2B4jQRUFQukK9V_QemRsW9g@mail.gmail.com> References: <CACfq090r1tWhuDkxdSZ24fwafbVKU0yduu1yV2%2BoYo%2BwwT4ipA@mail.gmail.com> <20120603051904.GG2358@deviant.kiev.zoral.com.ua> <20120603184315.T856@besplex.bde.org> <201206041101.57486.jhb@freebsd.org> <20120604181917.GD85127@deviant.kiev.zoral.com.ua> <CACfq0933BwaverZinGvKtErPvdZp%2B4jQRUFQukK9V_QemRsW9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Y+xroYBkGM9OatJL Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 04, 2012 at 11:16:10PM +0200, Giovanni Trematerra wrote: > On Mon, Jun 4, 2012 at 8:19 PM, Konstantin Belousov <kostikbel@gmail.com>= wrote: > > On Mon, Jun 04, 2012 at 11:01:57AM -0400, John Baldwin wrote: > >> On Sunday, June 03, 2012 6:49:27 am Bruce Evans wrote: > >> > On Sun, 3 Jun 2012, Konstantin Belousov wrote: >=20 > >> I think duplicating this logic in userland would just be wasteful. =9A= I have > >> a private fast gettimeofday() at my current job and it works by export= ing > >> the current timehands structure (well, the equivalent) to userland. = =9AThe > >> userland bits then fetch a copy of the details and do the same as bint= ime(). > >> (I move the math (bintime_addx() and the multiply)) out of the loop ho= wever. > > I started yesterday an implementation which uses shared page to export > > some variant of timehands, and uses auxv to provide the libc with a poi= nter > > to timehands when rdtsc is reasonable. > > > > I almost finished both 32bit and 64bit userspace, but there is > > kernel-side work left. Is your implementation ready or close to be ready > > for commit ? In other words, should I drop the efforts, or continue ? > > >=20 > Hey wait, What are you doing? > This is completely unfair. You didn't even review my patch. I did. I am quite saddened if you did not note that I did reviewed your patch. > I really don't understand your way to completely ignore me and start impl= ement > yesterday something you didn't care about for more than 3 years. > It costs me a lot of time and energy and I think I deserve more respect t= hat > just be ignored. I did not ignored the problem for 3 years. In fact, I did some, IMO non-trivial development moving the whole issue forward. In particular, I developed the shared page infrastructure that are currently used (yes, we already do have properly implemented shared page and sub-allocator of memory from it). I did some relevant rtld and libc changes, in particular, libc now have full access and uses auxv. So I consider this statement as a form of insult. I indeed never had much desire to delve into the timekeeping code. But periodically raising discussions, and final flamefest about the issue made me realize that I spent more efforts discussing the 'shared page' 'idea' then it would be to implement fast gettimeofday() and clock_gettime() using existing infrastructure. Having my hands somewhat deep into our ABI/ELF everything, I very much want to not paint myself into corner with unsustaining decisions that make ABI maintainance problematic. So I decided to save my time and implement it 'properly', to close the question and possibly remove the item from the ideas page. Please note that what I do now is still not a vdso. It does allow the vdso to plug into the framework later, but currently I only plan to reuse shared page and auxv transport to implement gettimeofday without usermode->kernelmode trip. If you want to do full-flesged vdso at once, I will be very much pleasured and probably support this work technically. For posted patch, I do respond with the NACK. --Y+xroYBkGM9OatJL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/NMrIACgkQC3+MBN1Mb4i3NACePjulGq8ZJL/dXcHjRCmvf3M7 1EIAnjkQGFTHATGrwScdXfF08wQ19zzp =FgPt -----END PGP SIGNATURE----- --Y+xroYBkGM9OatJL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120604221202.GG85127>