Re: [Xen-devel] [PATCH] Yield to VCPU hcall, spinlock yielding
Orran Y Krieger wrote:
"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> wrote on 06/08/2005 05:29:21 PM:
> > I'd view your "cpu_power" proposal as orthogonal to (or
> > perhaps complementary to) our ideas on preemption
> > notification. It's aimed more at load-balancing and fair
> > scheduling than specifically at the problems that arise with
> > the preemption of lock holders. On the apparent CPU speed
> > issue, does Linux account in any way for different interrupt
> > loads on different processors? Is a program just out of luck
> > if it happens to get scheduled on a processor with heavy
> > interrupt traffic, or will Linux notice that it's not making
> > the same progress as its peers and shuffle things around? It
> > seems that your cpu_power proposal might have something to
> > contribute here.
> I don't see it as orthogonal -- I think something like it is needed to
> make the notification scheme result in any benefit, otherwise no work
> will get migrated from the de-scheduled CPU.
I don't get it. If an application lock is important, and all the app
threads block on it except the one of the preempted processor, and the
preempted processor has two threads on it (the high priority kernel
and the app that was preempted), then we have one (or more) idle
processors and one processor with two threads. Hopefully the
scheduler is smart enough to move the preempted thread over. So, the
base scheme should result in processors from staying idle.... A
scheme like described above would be great, but without any changes we
have a scheme that keeps processors from going idle I think.
I take it this assumes nothing else is running on that domain? I agree
in this ideal scenerio, it would work (assumming the app threads waiting
for the lock are not busy waiting), but what about apps which have other
threads which don't wait on that particular lock, keeping the other cpus
busy, or a domain with more than one app running? In those cases the
load balance would probably not happen, and I would think we need more
than just the high prio kernel thread to move the desired task to a
active virtual cpu.
I'm not saying it's all or none either. Gettng the kernel thread
implemented is probably the next logial step. I would just like to
follow through with some extra logic if possible.
> I'm just not sure how easy it will be to add into the rebalance
There is already an abstractoin of "load" for each cpu in 2.6.11. We
just need some bits there. I will take a look.
Xen-devel mailing list