Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Jun 2012 14:39:16 +0200
From:      Momchil Ivanov <momchil@xaxo.eu>
To:        Daniel Kalchev <daniel@digsys.bg>
Cc:        freebsd-stable@freebsd.org, Momchil Ivanov <momchil@xaxo.eu>
Subject:   Re: ULE Scheduler
Message-ID:  <868vfq130r.wl%momchil@xaxo.eu>
In-Reply-To: <4FD8A86B.4010802@digsys.bg>
References:  <861ulkkflm.wl%momchil@xaxo.eu> <201206121203.q5CC3AA2002709@lurza.secnetix.de> <86zk88isor.wl%momchil@xaxo.eu> <4FD8A86B.4010802@digsys.bg>

next in thread | previous in thread | raw e-mail | index | archive | help
At Wed, 13 Jun 2012 17:49:15 +0300,
Daniel Kalchev wrote:
> 
> 
> 
> On 12.06.12 16:08, Momchil Ivanov wrote:
> > So the L2 cache is shared between both cores and hence it's size does 
> > not matter at all?
> 
> If the cache is shared between both cores then it does not matter on 
> which core the process runs, as long as data is in teh case. The cache 
> size is irrelevant.
> 
> Some CPUs have shared cache between cores, some don't. The ULE scheduler 
> takes this into account, the 4BSD does not. Even if the ULE scheduler 
> takes the CPU topology into consideration, if you only have two cores, 
> it is almost guaranteed that processes will be switched between both, 
> because the OS is running way more than two processes "at the same time".
> 
> Even with more cores... it is not guaranteed an computational process 
> won't be 'bouncing'. Here is an example.
> Suppose you have an 8 core (or threads) CPU. If you happen to have an 
> modern Ethernet controller, like the Intel 82576 (the igb driver in 
> FreeBSD), then it will use up to 8 interrupt lines, by default routing 
> them each to a different core. Then, if you have heavier network 
> traffic, chances are that at any given moment all 8 interrupts might be 
> fired and all 8 cores switched to service network traffic -- removing 
> your computational process from the running queue. The next time it 
> runs, it might run on any other core, especially if the cache is not shared.
> 
> Of course, if you have sufficiently large number of CPUs, you can 
> configure your system so that such things do not happen, like by 
> limiting the number of cores the igb driver attaches to, and have some 
> of the cores dedicated to 'only' running an computational task.
> 
> There is however, very little sense doing so.

OK, thank you for the explanation.

Regards,
Momchil



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?868vfq130r.wl%momchil>