On 19/10/2018 02.26, Subhra Mazumdar wrote:Can you point to where the leader is sending the IPI to other siblings?
Hi Jan,Hi. Sorry for the delay.
On 9/7/18 2:39 PM, Jan H. SchÃnherr wrote:The delay is roughly equivalent to the IPI latency, if we're just talking
The collective context switch from one coscheduled set of tasks to anotherDo you know how much is the delay? i.e what is overlap time when a thread
-- while fast -- is not atomic. If a use-case needs the absolute guarantee
that all tasks of the previous set have stopped executing before any task
of the next set starts executing, an additional hand-shake/barrier needs to
of new group starts executing on one HT while there is still thread of
another group running on the other HT?
about coscheduling at SMT level: one sibling decides to schedule another
group, sends an IPI to the other sibling(s), and may already start
executing a task of that other group, before the IPI is received on the
Now, there are some things that may delay processing an IPI, but in those
cases the target CPU isn't executing user code.
I've yet to produce some current numbers for SMT-only coscheduling. An
older ballpark number I have is about 2 microseconds for the collective
context switch of one hierarchy level, but take that with a grain of salt.