getting the cpuid for a userspace process ?

[Luigi Rizzo]

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)

thanks
luigi
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[John Baldwin]

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.

--
John Baldwin

[Poul-Henning Kamp]

In message <20111025134...@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 ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Kostik Belousov]

On Tue, Oct 25, 2011 at 01:42:45PM -0400, John Baldwin wrote:
> 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.

Not quite so. The kern.proc sysctls do provide oncpu and lastcpu
information, which, I believe, is used by top. But this is very slow way
to get cpu id.

[Dan Nelson]

In the last episode (Oct 25), Poul-Henning Kamp said:
> In message <20111025134...@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 ?

Looking at the source, it just determines the number of CPUs, creates a
number of arenas proportional to that, and assigns threads to an arena. If
contention on a particular arena gets bad, the thread gets moved to another
areana (see everything inside "#ifdef MALLOC_BALANCE" blocks).

--
Dan Nelson
dne...@allantgroup.com

[John Baldwin]

On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote:
> In message <20111025134...@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.

--
John Baldwin

[C. P. Ghost]

On Tue, Oct 25, 2011 at 8:54 PM, John Baldwin <j...@freebsd.org> wrote:
> On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote:
>> In message <20111025134...@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/