On 09/24/2012 06:21 PM, Avi Kivity wrote:
> On 09/24/2012 06:13 PM, Peter Zijlstra wrote:
> > On Mon, 2012-09-24 at 18:10 +0200, Avi Kivity wrote:
> >> > Its also still a LAPIC write -- disguised as an MSR though :/
> >>
> >> It's probably a whole lot faster though.
> >
> > I've been told its no
On 09/24/2012 06:13 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 18:10 +0200, Avi Kivity wrote:
>> > Its also still a LAPIC write -- disguised as an MSR though :/
>>
>> It's probably a whole lot faster though.
>
> I've been told its not, I haven't tried it.
I'll see if I can find a machine
On Mon, 2012-09-24 at 18:10 +0200, Avi Kivity wrote:
> > Its also still a LAPIC write -- disguised as an MSR though :/
>
> It's probably a whole lot faster though.
I've been told its not, I haven't tried it.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a messa
On 09/24/2012 06:05 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 17:58 +0200, Avi Kivity wrote:
>> There is the TSC deadline timer mode of newer Intels. Programming the
>> timer is a simple wrmsr, and it will fire immediately if it already
>> expired. Unfortunately on AMDs it is not availabl
On Mon, 2012-09-24 at 17:58 +0200, Avi Kivity wrote:
> There is the TSC deadline timer mode of newer Intels. Programming the
> timer is a simple wrmsr, and it will fire immediately if it already
> expired. Unfortunately on AMDs it is not available, and on virtual
> hardware it will be slow (~1-2
On 09/24/2012 05:52 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 17:43 +0200, Avi Kivity wrote:
>> Wouldn't this correspond to the scheduler interrupt firing and causing a
>> reschedule? I thought the timer was programmed for exactly the point in
>> time that CFS considers the right time for
On Mon, 2012-09-24 at 17:43 +0200, Avi Kivity wrote:
> Wouldn't this correspond to the scheduler interrupt firing and causing a
> reschedule? I thought the timer was programmed for exactly the point in
> time that CFS considers the right time for a switch. But I'm basing
> this on my mental model
On 09/24/2012 05:34 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 17:26 +0200, Avi Kivity wrote:
>> I think this is a no-op these (CFS) days. To get schedule() to do
>> anything, you need to wake up a task, or let time pass, or block.
>> Otherwise it will see that nothing has changed and as fa
On Mon, 2012-09-24 at 17:26 +0200, Avi Kivity wrote:
> I think this is a no-op these (CFS) days. To get schedule() to do
> anything, you need to wake up a task, or let time pass, or block.
> Otherwise it will see that nothing has changed and as far as it's
> concerned you're still the best task to
On 09/21/2012 03:00 PM, Raghavendra K T wrote:
> From: Raghavendra K T
>
> When PLE handler fails to find a better candidate to yield_to, it
> goes back and does spin again. This is acceptable when we do not
> have overcommit.
> But in overcommitted scenarios (especially when we have large
> numb
On Fri, 21 Sep 2012 23:15:40 +0530
Raghavendra K T wrote:
> >> How about doing cond_resched() instead?
> >
> > Actually, an actual call to yield() may be better.
> >
> > That will set scheduler hints to make the scheduler pick
> > another task for one round, while preserving this task's
> > top p
On 09/21/2012 07:22 PM, Rik van Riel wrote:
On 09/21/2012 09:46 AM, Takuya Yoshikawa wrote:
On Fri, 21 Sep 2012 17:30:20 +0530
Raghavendra K T wrote:
From: Raghavendra K T
When PLE handler fails to find a better candidate to yield_to, it
goes back and does spin again. This is acceptable whe
On 09/21/2012 09:46 AM, Takuya Yoshikawa wrote:
On Fri, 21 Sep 2012 17:30:20 +0530
Raghavendra K T wrote:
From: Raghavendra K T
When PLE handler fails to find a better candidate to yield_to, it
goes back and does spin again. This is acceptable when we do not
have overcommit.
But in overcommi
On Fri, 21 Sep 2012 17:30:20 +0530
Raghavendra K T wrote:
> From: Raghavendra K T
>
> When PLE handler fails to find a better candidate to yield_to, it
> goes back and does spin again. This is acceptable when we do not
> have overcommit.
> But in overcommitted scenarios (especially when we have
On 09/21/2012 08:00 AM, Raghavendra K T wrote:
From: Raghavendra K T
When PLE handler fails to find a better candidate to yield_to, it
goes back and does spin again. This is acceptable when we do not
have overcommit.
But in overcommitted scenarios (especially when we have large
number of small
15 matches
Mail list logo
