* Chuck Ebbert <[email protected]> wrote:
> Use a GDT entry's limit field to store per-cpu data for fast access
> from userspace, and provide a vsyscall to access the current CPU
> number stored there.
very nice idea! I thought of doing sys_get_cpu() too, but my idea was to
use the scheduler to keep a writable [and permanently pinned,
per-thread] VDSO data page uptodate with the current CPU# [and other
interesting data]. Btw., do we know how fast LSL is on modern CPUs?
> Questions:
> 1. Will the vdso relocation patch break this?
no - why should it?
> 2. Should the version number of the vsyscall .so be incremented?
i've Cc:-ed the glibc folks.
but my gut feeling is that we should add a proper sys_get_cpu() syscall
as well, and thus make this a transparent syscall, not dependent on the
availability of the vDSO.
> +__vgetcpu:
> +.LSTART_vgetcpu:
> + movl $-EFAULT,%eax
> + movl $((27<<3)|3),%edx
> + lsll %edx,%eax
> + jnz 1f
> + andl $0xff,%eax
> +1:
> + ret
this needs unwinder annotations as well to make this a proper DSO, so
that for example a breakpoint here does not confuse gdb.
also, would be nice to do something like this in 64-bit mode too.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
