Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Nov 2011 03:01:05 +0100
From:      "C. P. Ghost" <cpghost@cordula.ws>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>
Subject:   Re: getting the cpuid for a userspace process ?
Message-ID:  <CADGWnjWOfaWftV_Zr_J0b%2B-KeR6qfXnkXipSmv1RXeyLarUZsA@mail.gmail.com>
In-Reply-To: <201110251454.00471.jhb@freebsd.org>
References:  <99483.1319566152@critter.freebsd.dk> <201110251454.00471.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 25, 2011 at 8:54 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote:
>> In message <201110251342.45194.jhb@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. =A0On 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. =A0The only thing malloc() knows on Fre=
eBSD is
> the total number of CPUs. =A0I believe Linux has a system call that retur=
ns this
> though (sched_getcpu() is the public interface which is a wrapper around =
a
> getcpu() system call). =A0From the manpage it would seem that sched_getcp=
u()
> uses a per-thread shared page of some sort so that it doesn't actually ha=
ve to
> enter the kernel to get the CPU ID. =A0Alternatively, you could imagine i=
t 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. =A0That would o=
nly
> necessitate a global shared page and not one per-thread. =A0You could sti=
ll 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/dd624dde5bce4ab120b2fcecbbcd94473eff=
b201/kernel/src/glue/v4-x86/utcb.h

> --
> John Baldwin

-cpghost.

--=20
Cordula's Web. http://www.cordula.ws/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADGWnjWOfaWftV_Zr_J0b%2B-KeR6qfXnkXipSmv1RXeyLarUZsA>