Fast vs slow syscalls (Re: Fwd: [RFC] Kernel shared variables)

[Konstantin Belousov]

On Thu, Jun 07, 2012 at 03:30:54PM -0700, Peter Wemm wrote:
> On Thu, Jun 7, 2012 at 1:26 AM, Dag-Erling Sm?rgrav <des at des.no> wrote:
> > Bruce Evans <brde at optusnet.com.au> writes:
> >> Now 2.44 nsec/call makes sense, but you really should add some volatiles
> >> here to ensure that getpid() is not optimized away.
> >
> > As you can see from the disassembly I provided, it isn't.
> >
> >> SO it loops OK, but we can't see what getpid() does.  It must not be
> >> doing much.
> >
> > Umm, yes, that's the whole point of this conversation.  Linux's getpid()
> > is not a syscall, but a library function that returns a constant from a
> > page shared by the kernel.
> 
> It might be worth taking a peek at what they do before going too far
> down the rabbit hole.  They've had to deal with the whole ABI
> stability vs kernel layout thing already.
> 
> As I recall, they literally embed a userland style .so shared object
> into the kernel and make it available to the user.  The dynamic linker
> "finds" it via elf auxinfo and inserts it into the symbol search
> order.
> 
> That way, the shared page layout is kernel specific.  If they chose to
> provide getpid() or gettimeofday() or whatever, its a matter of
> adjusting the shared page and inserting code into the .so file.  If
> the page changes, the code changes.
> 
> Think of what we do with signal trampolines except in a way
> ld-elf.so.1 can pull it into user space and gdb "sees" it as a .so
> file with debug info.
> 
> I think I remember that they did the shared page thing and then
> switched to providing a stub .so file.

Yes, this is the thing called VDSO in the thread discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120607/66698849/attachment.pgp