Date: Fri, 28 Oct 2005 16:54:32 -0700 From: Maxim Sobolev <sobomax@portaone.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Pertti Kosunen <pertti.kosunen@pp.nic.fi>, Robert Watson <rwatson@FreeBSD.ORG>, David Xu <davidxu@FreeBSD.ORG>, "Yuriy N. Shkandybin" <jura@networks.ru>, current@FreeBSD.ORG Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <4362BA38.1090603@portaone.com> In-Reply-To: <32412.1130505646@critter.freebsd.dk> References: <32412.1130505646@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <20051028140556.W20147@fledge.watson.org>, Robert Watson writes: > >>On Fri, 28 Oct 2005, David Xu wrote: >> >> >>>Poul-Henning Kamp wrote: >>> >>>>In message <4361FDBE.7000500@freebsd.org>, David Xu writes: >>>> >>>>the correct way to optimize this would be to add a time(2) systemcall >>>>which returns the value of the kernel global time_second. >>> >>>Can we make a page in kernel address space which is readable my user >>>code? put the variable in the page, I know read an integer is atomic-op, >>>needn't lock, so syscall is not needed. >> >>This approach has a lot of merit, as we can also potentially export other >>information there (such as kernel preferences for system call mechanisms). > > > Yes, there are many advantages to this approach, but we need a solution > to the API versioning problem before we head that way. > > For anyone wanting to look at this, three are a number of nasties > to remember: > > 1. How does userland get hold of the page ? Does it open a magic > device ? Use a magic syscall ? Or does all processes just get > the page by default ? > > 2. Where in the address space do we put it ? > > 3. Layout and alignment issues. Remember that things change size > over time. (Version numbers for each element ?) And that cross- > arch support is desirable (32bit i386 binaries on 64bit amd64 arch) > > 4. Do guarantee a syscall fallback for all facilities if there is version > skew, or do we abort the program ? > > 5. Do we want a global system page and a per process page while we > are at it. There is plenty of stuff we could put in the per-proc > page: pid, ppid, resource usage, proctitle etc. You can solve most of those issues by exporting from kernel to userland not only page(s) with actual data, but also page(s) with code to handle that data. Then you can turn syscalls implementation in libc into plain function calls to addresses in that code page(s). This approach can potentially have other interesting applications, for example it will be possible to use processor-specific syscalls instructions without recompiling userland, move some of the ABI code into userland (i.e. freebsd32 layer on amd64) etc. -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4362BA38.1090603>