On Tue, Oct 25, 2011 at 8:54 PM, John Baldwin <jhb_at_freebsd.org> wrote: > On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote: >> In message <201110251342.45194.jhb_at_freebsd.org>, John Baldwin writes: >> >On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: >> >> as the subject says... is there any way to get the current >> >> CPU id for a userspace process (of course, >> >> valid only at the time the function is called as the >> >> process might be arbitrarily moved while it runs) >> > >> >Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, but >> >that does not map 1:1 to FreeBSD cpu IDs. >> >> How does JEmalloc do it ? > > I don't think it does on FreeBSD. The only thing malloc() knows on FreeBSD is > the total number of CPUs. I believe Linux has a system call that returns this > though (sched_getcpu() is the public interface which is a wrapper around a > getcpu() system call). From the manpage it would seem that sched_getcpu() > uses a per-thread shared page of some sort so that it doesn't actually have to > enter the kernel to get the CPU ID. Alternatively, you could imagine it on > x86 at least exporting a table mapping APIC IDs to CPU IDs and then using > cpuid and that table to do the lookup purely in userland. That would only > necessitate a global shared page and not one per-thread. You could still fall > back to a system call for other architectures that simply returned > curthread->td_oncpu. Exposing a table mapping to userland would be somewhat similar to the way L4Ka::Pistachio exports a UTCB area to userland threads: https://github.com/l4ka/pistachio/blob/dd624dde5bce4ab120b2fcecbbcd94473effb201/kernel/src/glue/v4-x86/utcb.h > -- > John Baldwin -cpghost. -- Cordula's Web. http://www.cordula.ws/Received on Fri Nov 04 2011 - 01:01:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC