On Thu, Nov 10, 2005 at 10:26:12 +0000, Bahadir Balban wrote: > On 11/10/05, Jan Hudec <bulb@xxxxxx> wrote: > > I don't know about runqueue balancing, at least not by that name, but a > > few comments anyway: > > By that I actually meant *load balancing*, i.e. the balancing of > processes among available CPUs, which involves balancing of the > runqueues across CPUs (or so it says in linux kernel development). I > see that this may be confusing. Yes, I understood that from the last paragraph. > > It did disable BHs, because the BH can run on any CPU. It depends on > > which CPU first reaches point suitable for running the BH. I am not sure > > whether it depends on which CPU the interrupt was handled on, but that > > can still be any of them. > > OK, Here I thought because softirq daemons are per processor, the > bottom halves associated would be per processor, too. But I see that > there's no such guarantee. Also interrupts would most likely be > arbitrated among CPUs, and there's no guarantee that they run on a > particular CPU, unless the HW is set up to do otherwise. I don't know whether BH queues are per-CPU. But it does not really matter when interrupts are arbitrated. On the other hand both IRQ and BH disabling is CPU-local. When disabled on one CPU, another CPU can still run them. Also the code in kernel should be simple and generic. If the code was conditional on whether that interrupt can actually happen on that CPU, it would be very error-prone and the cost of the test would probably exceed the benefits anyway - spinlocks are usually held very shortly, so the interrupt is not delayed very often. -- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
