Timers and timing, was: MySQL Performance 6.0rc1
Peter Jeremy
PeterJeremy at optushome.com.au
Sat Oct 29 01:37:21 PDT 2005
On Sat, 2005-Oct-29 00:29:10 -0700, Maxim Sobolev wrote:
>Poul-Henning Kamp wrote:
>>In message <4362BA38.1090603 at portaone.com>, Maxim Sobolev writes:
>>>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.
The data I understand - we document a struct that defines the page
contents, I'm less sure about the code. The concept is appealing
but some more detail would be nice.
>>I'm not sure I see much difference between a shared library and this
>>solution, but I'm equally sure we'd love to se a prototype before
>>we judge it :-)
>
>Difference is that you won't have additional problems with userland and
>kernel versions mismatch and don't need any additional complexity
>associated with versioning/fallback logic.
I'm not sure I understand how you'll achieve this. How would a userland
application locate the appropriate entry points? If the exported code
looks like a automagically-mapped shared library, we'd need to embed the
ELF symbol table in the kernel as well. How does an application compiled
for (eg) FreeBSD-6 handle the code page exported by a FreeBSD-7 kernel?
Other options would seem to be:
- hard-wire the entry-points into the application or libc (which will
basically destroy backward/forward compatibility)
- Use explicit branch tables (ala Amiga shared libraries) - there's no
infrastructure to support this in FreeBSD.
--
Peter Jeremy
More information about the freebsd-current
mailing list