Re: sched_setaffinity usability

[Andrea Arcangeli]

On Thu, Mar 18, 2004 at 07:39:44PM +0100, Ingo Molnar wrote:
> 
> * Andrew Morton <akpm@xxxxxxxx> wrote:
> 
> > >  Right now the VDSO mostly contains code and exception-handling data, but
> > >  it could contain real, userspace-visible data just as much: info that is
> > >  only known during the kernel build. There's basically no cost in adding
> > >  more fields to the VDSO, and it seems to be superior to any of the other
> > >  approaches. Is there any reason not to do it?
> > 
> > It's x86-specific?
> 
> x86-64 has a VDSO page as well, and it can be implemented on any

it doesn't.

> architecture that wants to accelerate syscalls in user-space (and/or

x86-64 is the first arch ever implementing vsyscalls in production with
the fastest possible API.

The API doesn't contemplate the idea of relocating the vsyscall address,
but it can be extended easily with a relocation API.

> wants to provide alternate methods of system-entry).

there's no need of alternate methods of system-entry in x86-64, luckily
Intel merged the optimal extremely optimized syscall/sysexit from AMD
instead of only providing sysenter/sysexit like they do in the 32bit
cpus.

The way x86-64 implements the entry.S code is ultraoptimized since we
don't save a full stack for all syscalls except fork and few othrs that
needs to see all the registers, we've two different stack frames
depending on which syscalls is running.

Intel also provides sysenter/sysexit but that's useless on 64bit since
syscall/sysret is the standard in 64bit mode.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/