Thanks Wojciech for the quick reply. I read about rcu offloading and in my
testing, can confirm that kernel rcu threads are scheduled on core 0 even
if core 0 is isolated. Another thing I observed was that there are some
kworker threads which run on isolated cpus other than 0. Is this expected
behavior, because I used to think that isolated cpus are not touched by the
kernel. These kworker threads will definitely lead to context switches and
hamper performance a little bit. And I am afraid we can do nothing to get
rid of them.

Himanshu Sharma


On Mon, May 22, 2017 at 2:08 PM, Wojciech Kudla <wojciech.ku...@gmail.com>
wrote:

> There's a number of kernel tasks that are implicitly bound to cpu0. For an
> example of one have a look at rcu offloading and its restrictions.
>
> On Mon, 22 May 2017, 08:59 Himanshu Sharma, <imhimansh...@gmail.com>
> wrote:
>
>> Hi Michael
>>
>> Did you find a satisfactory reason for not isolating cpu 0, maybe some
>> low level OS code that is bound to run on core 0? I am also stuck at this
>> question right now and am thinking you might have an answer.
>>
>> Thanks
>> Himanshu
>>
>> On Wednesday, March 4, 2015 at 8:08:22 PM UTC+5:30, Michael Mattoss wrote:
>>>
>>> Hi guys,
>>>
>>> I'm in the process of setting up a new dual-socket server for a low
>>> latency workload.
>>> The application will run exclusively on one CPU and everything else
>>> (i.e. OS, non-critical processes) will run on the other CPU to avoid cache
>>> pollution.
>>> I was wondering if it makes any difference as to which one of the
>>> 2 CPU's is chosen for the workload.
>>> Theoretically, there should be no difference but I was wondering if
>>> there is some low-level stuff (e.g. core OS code, system management
>>> interrupts handlers) that is statically allocated to CPU-0 as every system
>>> has at least 1 CPU.
>>> Of course, if that's the case then CPU-1 is the better choice.
>>>
>>> Any thoughts/suggestions?
>>>
>>> Thanks,
>>> Michael
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "mechanical-sympathy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mechanical-sympathy+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "mechanical-sympathy" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/mechanical-sympathy/SnJ6LTKCjEU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> mechanical-sympathy+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to