noob question: way to know which CPU current proc running

[ggodw000]

if you are running a kernel with multiple processes running on MP systems, is there a way to know which CPU socket/core/thread the current process is running?
I am looking through MSRs and also ACPI APIC table that might give some clue.
Thanks.,

[BrightLight]

if you are running a kernel with multiple processes running on MP systems, is there a way to know which CPU socket/core/thread the current process is running?
I am looking through MSRs and also ACPI APIC table that might give some clue.
Thanks.,

The scheduler probably keeps a variable called current_task or something like that. If the scheduler supports multiprocessing, then the task structure probably contains the APIC number of the CPU on which the task running, which is normally between and including 0 and 15. I'm not sure if you can find out which socket/core the CPU is without chipset-specific methods, but knowing which CPU local APIC ID should be enough.

[gerryg400]

I have a data structure for each core. It currently looks like this

Code: Select all

extern "C" typedef struct core_data
{
    struct core_data    *pself;         // offs = 0
    char                *kstack;        // offs = 8
    Thread              *curr_thread;   // offs = 16
    uint64_t            scratch;        // offs = 24
    tss64_t             *tss;           // offs = 32
    int                 core_id;        // offs = 40
    int                 core_nest;      // offs = 44
    int                 core_state;     // offs = 48
    kjmpbuf_t           jmpbuf;
    int                 need_preempt;
    Thread              *fpu_owner;
    mm_context          *curr_ctx;
    int                 apic_id;
    int                 cnt;
} __attribute__ ((packed)) core_data_t;

As each core comes up it increments an atomic variable and that becomes its core_id. Independent of APIC id etc. Then the core stores the address of its data in its 'swapgs' register.

Code: Select all

    /* Set up the gs register */
    wr_msr(0xc0000102, (uintptr_t)&core_data[core]);
    __swapgs();

Then each time it enters the kernel the core can find all its core private data like this.

Code: Select all

        /* Get the kernel GS selector */
        swapgs

Note that this data is independent of the process or thread that is currently running.

[BrightLight]

So you answered your own question: you have a way of identifying each CPU. Now just put the "CPU number" into each task structure; and then you know which CPU is executing which task.

[gerryg400]

gerryg400 != ggodw000. Similar but different.

[BrightLight]

gerryg400 != ggodw000. Similar but different.

Oops. My bad. I didn't notice.

[SpyderTL]

The local APIC knows what the CPU APIC ID is. You can read it at any time if you are in Ring 0. Otherwise you can call a kernel function to get the value for you.

By default the current CPU APIC ID is located in a 32-bit register at address 0xfee00020. I believe the value is located in the top 8 bits of this register.

[ggodw000]

gerryg400 != ggodw000. Similar but different.

here is my schema:
FirstName[0]+LastName[0]+(some.uniq.representitive.abbreviation.of.domain.name)+000.
If account ever fails due to loss of password, unable to retrieve and any other reason, increment 000 to 001 etc and create new one.

[Brendan]

Hi,

if you are running a kernel with multiple processes running on MP systems, is there a way to know which CPU socket/core/thread the current process is running?

First, a multi-threaded process may be running on multiple CPUs at the same time.

Second; typically (for OSs that support pre-emption) due to race conditions you can only know which CPU you were running on (which may be different to which CPU you are currently running on). For a simple example, you can use the RDTSCP instruction (in user-space) to get the "CPU ID" set by the kernel, but immediately after you've executed this instruction the OS can do a task switch and the next instruction might be using a different CPU - the "which CPU" information can be stale/obsolete before you can use it for anything.

It's only possible if something prevents the "running on a different CPU" problem. In kernel-space this is likely easy to do temporarily (just disable task switches). For user-space (and kernel, for longer periods of time) kernel can support "CPU affinity" (e.g. a flag for each CPU saying if the thread is/isn't allowed to use the CPU) that user-space can change, so user-space code can get the CPU it was running on, set the CPU affinity to that CPU, and then know that it is running on that CPU from that point on. Of course if kernel does support "CPU affinity" (either per thread, or per process) it should be easy to determine the set of CPUs that a process (or thread) might use.

Fortunately; for user-space there's very few reasons to actually care which CPU you're using that doesn't require CPU affinity anyway. For example, if one CPU supports a feature and another CPU doesn't then you can't do "If running on CPU that supports feature, use code that uses feature, else use alternative code that doesn't use the feature", and you'd have to use CPU affinity to ensure you're only ever run on the CPUs that support the feature.

For kernel space; most OS's have some form of "per CPU data" (e.g. using a segment register like FS or GS to point to the "per CPU data" for the current CPU, or using paging). In this case kernel code can use "per CPU data" without caring which CPU it is. For example, maybe you can do "mov eax,[gs:CPUdata.CPUload]" to get the current CPU's load. You can also store a "CPU ID" in the "per CPU data".

For the other part of your question (determining socket/core/thread from the "CPU ID"), there's a "Detecting CPU Topology" wiki page. This information can be put into each CPU's "per CPU data" too; so that (e.g.) kernel can do "mov eax,[gs:CPUdata.CPUsocket]" to determine which socket (or which core within the socket, or which logical CPU/thread within the core).


Cheers,

Brendan