Hi @Richard, CPU socket (also processor socket) means the connector on the motherboard that houses a CPU and forms the electrical interface and contact with the CPU
Can someone explain to me how did we come up with 24 execution contexts to fill? Does each core has two execution context?
Richard
@Dracula08MS Yes.
fleventyfive
It is important to note that although the processor presents itself as having a total of 24 contexts, the OS knows which of those contexts are actually execution contexts on the same core, the physical layout of all cores, etc., so that it can make intelligent scheduling decisions by taking into account various factors such as locality, working sets, arithmetic intensity etc.
captainFlint
Is the cache coherence protocol used in case of a two-socket system very different from a directory-based approach since we need to move data not only between different cores but also different sockets? It seems to me that a directory-based approach would not be super efficient. However, I don't know of any other way it could be done.
yimmyz
An interesting point that Prof Kayvon brought up on this slide is that we as programmers are allowed to give "hints" to how threads are allocated to processors. While doing Assignment 4, we learnt that it's called processor affinity, which is accessible as pthread.h library function (e.g. pthread_setaffinity_np).
One question I have though is about the implementation details of processor affinity -- how can we change the allocation of threads on processors at software level? Is there a system call for this?
aarumuga
-bash-4.2$ lscpu
CPU(s):24 (socket(2) * (6)cores per socket * (2)threads per core)
On-line CPU(s) list:0-23,
Thread(s) per core:2 (number of execution context per core)
Core(s) per socket:6 (number of cores in each physical processor)
Socket(s): 2 (num of physical processors on the chip)
NUMA node(s):2
dL1d cache:32K
L1i cache:32K
L2 cache:256K
L3 cache:12288K
NUMA node0 CPU(s):0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s):1,3,5,7,9,11,13,15,17,19,21,23
bdebebe
@aarumuga From what I understand lscpu is basically a command in linux that let's you see information about your computer's architecture. Is that supposed to be a response to @yimmyz? I don't see how this can help us change the allocation of threads on processors at software level.
vincom2
at least on linux, the relevant syscall is sched_setaffinity, I think.
What does socket mean here?
Hi @Richard, CPU socket (also processor socket) means the connector on the motherboard that houses a CPU and forms the electrical interface and contact with the CPU
Pictures tell a thousand words:
http://www.servethehome.com/wp-content/uploads/2014/01/Gigabyte-GA-7PESH3-Overview.jpg
Can someone explain to me how did we come up with 24 execution contexts to fill? Does each core has two execution context?
@Dracula08MS Yes.
It is important to note that although the processor presents itself as having a total of 24 contexts, the OS knows which of those contexts are actually execution contexts on the same core, the physical layout of all cores, etc., so that it can make intelligent scheduling decisions by taking into account various factors such as locality, working sets, arithmetic intensity etc.
Is the cache coherence protocol used in case of a two-socket system very different from a directory-based approach since we need to move data not only between different cores but also different sockets? It seems to me that a directory-based approach would not be super efficient. However, I don't know of any other way it could be done.
An interesting point that Prof Kayvon brought up on this slide is that we as programmers are allowed to give "hints" to how threads are allocated to processors. While doing Assignment 4, we learnt that it's called processor affinity, which is accessible as pthread.h library function (e.g.
pthread_setaffinity_np).One question I have though is about the implementation details of processor affinity -- how can we change the allocation of threads on processors at software level? Is there a system call for this?
-bash-4.2$ lscpu
CPU(s):24 (socket(2) * (6)cores per socket * (2)threads per core)
On-line CPU(s) list:0-23,
Thread(s) per core:2 (number of execution context per core)
Core(s) per socket:6 (number of cores in each physical processor)
Socket(s): 2 (num of physical processors on the chip)
NUMA node(s):2
dL1d cache:32K
L1i cache:32K
L2 cache:256K
L3 cache:12288K
NUMA node0 CPU(s):0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s):1,3,5,7,9,11,13,15,17,19,21,23
@aarumuga From what I understand lscpu is basically a command in linux that let's you see information about your computer's architecture. Is that supposed to be a response to @yimmyz? I don't see how this can help us change the allocation of threads on processors at software level.
at least on linux, the relevant syscall is
sched_setaffinity, I think.