Timers and timing, was: MySQL Performance 6.0rc1
Maxim Sobolev
sobomax at portaone.com
Fri Oct 28 16:54:48 PDT 2005
Poul-Henning Kamp wrote:
> In message <20051028140556.W20147 at fledge.watson.org>, Robert Watson writes:
>
>>On Fri, 28 Oct 2005, David Xu wrote:
>>
>>
>>>Poul-Henning Kamp wrote:
>>>
>>>>In message <4361FDBE.7000500 at 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
More information about the freebsd-current
mailing list