* Rik van Riel [2010-12-13 12:02:51]:
> On 12/11/2010 08:57 AM, Balbir Singh wrote:
>
> >If the vpcu holding the lock runs more and capped, the timeslice
> >transfer is a heuristic that will not help.
>
> That indicates you really need the cap to be per guest, and
> not per VCPU.
>
Yes, I pers
On 12/11/2010 08:57 AM, Balbir Singh wrote:
If the vpcu holding the lock runs more and capped, the timeslice
transfer is a heuristic that will not help.
That indicates you really need the cap to be per guest, and
not per VCPU.
Having one VCPU spin on a lock (and achieve nothing), because
the
On 12/13/2010 02:39 PM, Balbir Singh wrote:
* Avi Kivity [2010-12-13 13:57:37]:
> On 12/11/2010 03:57 PM, Balbir Singh wrote:
> >* Avi Kivity [2010-12-11 09:31:24]:
> >
> >> On 12/10/2010 07:03 AM, Balbir Singh wrote:
> >> >>
> >> >>Scheduler people, please flame me with anyth
* Avi Kivity [2010-12-13 13:57:37]:
> On 12/11/2010 03:57 PM, Balbir Singh wrote:
> >* Avi Kivity [2010-12-11 09:31:24]:
> >
> >> On 12/10/2010 07:03 AM, Balbir Singh wrote:
> >> >>
> >> >> Scheduler people, please flame me with anything I may have done
> >> >> wrong, so I can do it righ
On 12/11/2010 03:57 PM, Balbir Singh wrote:
* Avi Kivity [2010-12-11 09:31:24]:
> On 12/10/2010 07:03 AM, Balbir Singh wrote:
> >>
> >> Scheduler people, please flame me with anything I may have done
> >> wrong, so I can do it right for a next version :)
> >>
> >
> >This is a good pr
* Avi Kivity [2010-12-11 09:31:24]:
> On 12/10/2010 07:03 AM, Balbir Singh wrote:
> >>
> >> Scheduler people, please flame me with anything I may have done
> >> wrong, so I can do it right for a next version :)
> >>
> >
> >This is a good problem statement, there are other things to consider
> >
On 12/10/2010 07:03 AM, Balbir Singh wrote:
>
> Scheduler people, please flame me with anything I may have done
> wrong, so I can do it right for a next version :)
>
This is a good problem statement, there are other things to consider
as well
1. If a hard limit feature is enabled underneath,
On 12/10/2010 12:03 AM, Balbir Singh wrote:
This is a good problem statement, there are other things to consider
as well
1. If a hard limit feature is enabled underneath, donating the
timeslice would probably not make too much sense in that case
The idea is to get the VCPU that is holding the
* Rik van Riel [2010-12-02 14:41:29]:
> When running SMP virtual machines, it is possible for one VCPU to be
> spinning on a spinlock, while the VCPU that holds the spinlock is not
> currently running, because the host scheduler preempted it to run
> something else.
>
> Both Intel and AMD CPUs h
On 12/03/2010 12:41 AM, Chris Wright wrote:
* Rik van Riel (r...@redhat.com) wrote:
> When running SMP virtual machines, it is possible for one VCPU to be
> spinning on a spinlock, while the VCPU that holds the spinlock is not
> currently running, because the host scheduler preempted it to run
* Rik van Riel (r...@redhat.com) wrote:
> When running SMP virtual machines, it is possible for one VCPU to be
> spinning on a spinlock, while the VCPU that holds the spinlock is not
> currently running, because the host scheduler preempted it to run
> something else.
>
> Both Intel and AMD CPUs h
When running SMP virtual machines, it is possible for one VCPU to be
spinning on a spinlock, while the VCPU that holds the spinlock is not
currently running, because the host scheduler preempted it to run
something else.
Both Intel and AMD CPUs have a feature that detects when a virtual
CPU is spi
12 matches
Mail list logo
