On Wed, Mar 01, 2017 at 03:21:32PM +0100, Paolo Bonzini wrote:
>
>
> On 28/02/2017 03:45, Marcelo Tosatti wrote:
> > On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> >>> Whats the current usecase, or forseeable future
On Wed, Mar 01, 2017 at 03:21:32PM +0100, Paolo Bonzini wrote:
>
>
> On 28/02/2017 03:45, Marcelo Tosatti wrote:
> > On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> >>> Whats the current usecase, or forseeable future
On 28/02/2017 03:45, Marcelo Tosatti wrote:
> On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 24/02/2017 14:04, Marcelo Tosatti wrote:
>>> Whats the current usecase, or forseeable future usecase, for
>>> save/restore
>>> across preemption again? (which
On 28/02/2017 03:45, Marcelo Tosatti wrote:
> On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 24/02/2017 14:04, Marcelo Tosatti wrote:
>>> Whats the current usecase, or forseeable future usecase, for
>>> save/restore
>>> across preemption again? (which
On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> > Whats the current usecase, or forseeable future usecase, for
> > save/restore
> > across preemption again? (which would validate the broken by design
> > claim).
On Fri, Feb 24, 2017 at 04:34:52PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> > Whats the current usecase, or forseeable future usecase, for
> > save/restore
> > across preemption again? (which would validate the broken by design
> > claim).
On Friday, February 24, 2017 04:34:52 PM Paolo Bonzini wrote:
>
> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> > Whats the current usecase, or forseeable future usecase, for
> > save/restore
> > across preemption again? (which would validate the broken by design
> > claim).
>
On Friday, February 24, 2017 04:34:52 PM Paolo Bonzini wrote:
>
> On 24/02/2017 14:04, Marcelo Tosatti wrote:
> > Whats the current usecase, or forseeable future usecase, for
> > save/restore
> > across preemption again? (which would validate the broken by design
> > claim).
>
On 24/02/2017 14:04, Marcelo Tosatti wrote:
> Whats the current usecase, or forseeable future usecase, for save/restore
> across preemption again? (which would validate the broken by design
> claim).
Stop a guest that is using cpufreq, start a guest that is not using it.
On 24/02/2017 14:04, Marcelo Tosatti wrote:
> Whats the current usecase, or forseeable future usecase, for save/restore
> across preemption again? (which would validate the broken by design
> claim).
Stop a guest that is using cpufreq, start a guest that is not using it.
On Fri, Feb 24, 2017 at 01:17:07PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 12:50, Marcelo Tosatti wrote:
> >>>
> >>> On all other cpufreq implementations, these boundaries still need to
> >>> be set. Then, a "governor" must be selected. Such a "governor" decides
> >>> what speed the
On Fri, Feb 24, 2017 at 01:17:07PM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 12:50, Marcelo Tosatti wrote:
> >>>
> >>> On all other cpufreq implementations, these boundaries still need to
> >>> be set. Then, a "governor" must be selected. Such a "governor" decides
> >>> what speed the
On 24/02/2017 12:50, Marcelo Tosatti wrote:
>>>
>>> On all other cpufreq implementations, these boundaries still need to
>>> be set. Then, a "governor" must be selected. Such a "governor" decides
>>> what speed the processor shall run within the boundaries. One such
>>> "governor" is the
On 24/02/2017 12:50, Marcelo Tosatti wrote:
>>>
>>> On all other cpufreq implementations, these boundaries still need to
>>> be set. Then, a "governor" must be selected. Such a "governor" decides
>>> what speed the processor shall run within the boundaries. One such
>>> "governor" is the
On Fri, Feb 24, 2017 at 10:18:59AM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 00:19, Marcelo Tosatti wrote:
> >>> i.e. our feature implies userspace tasks pinned to isolated vCPUs.
> > This is how cpufreq-userspace works:
> >
> > 2.2 Governor
> >
> >
> > On all other cpufreq
On Fri, Feb 24, 2017 at 10:18:59AM +0100, Paolo Bonzini wrote:
>
>
> On 24/02/2017 00:19, Marcelo Tosatti wrote:
> >>> i.e. our feature implies userspace tasks pinned to isolated vCPUs.
> > This is how cpufreq-userspace works:
> >
> > 2.2 Governor
> >
> >
> > On all other cpufreq
On 24/02/2017 00:19, Marcelo Tosatti wrote:
>>> i.e. our feature implies userspace tasks pinned to isolated vCPUs.
> This is how cpufreq-userspace works:
>
> 2.2 Governor
>
>
> On all other cpufreq implementations, these boundaries still need to
> be set. Then, a "governor" must
On 24/02/2017 00:19, Marcelo Tosatti wrote:
>>> i.e. our feature implies userspace tasks pinned to isolated vCPUs.
> This is how cpufreq-userspace works:
>
> 2.2 Governor
>
>
> On all other cpufreq implementations, these boundaries still need to
> be set. Then, a "governor" must
it to a daemon in the host through virtio-serial
> or vsock.
>
> Paolo
Hypercalls overcome the problems mentioned in the first email
of the thread, i think you missed them:
"[patch 0/3] KVM CPU frequency change hypercalls"
it to a daemon in the host through virtio-serial
> or vsock.
>
> Paolo
Hypercalls overcome the problems mentioned in the first email
of the thread, i think you missed them:
"[patch 0/3] KVM CPU frequency change hypercalls"
On 03/02/2017 20:09, Radim Krcmar wrote:
> One reason why we have a kernel/userspace split is to allow sharing of
> CPU time. Each application then its state that the kernel keeps track
> of and saves/restores while time-multiplexing.
>
> Our frequency scaling interface goes against the idea
On 03/02/2017 20:09, Radim Krcmar wrote:
> One reason why we have a kernel/userspace split is to allow sharing of
> CPU time. Each application then its state that the kernel keeps track
> of and saves/restores while time-multiplexing.
>
> Our frequency scaling interface goes against the idea
2017-02-03 16:14-0200, Marcelo Tosatti:
> On Fri, Feb 03, 2017 at 05:43:50PM +0100, Radim Krcmar wrote:
>> 2017-02-02 15:47-0200, Marcelo Tosatti:
>> > Implement KVM hypercalls for the guest
>> > to issue frequency changes.
>> >
>> > Current situation with DPDK and frequency changes is as
2017-02-03 16:14-0200, Marcelo Tosatti:
> On Fri, Feb 03, 2017 at 05:43:50PM +0100, Radim Krcmar wrote:
>> 2017-02-02 15:47-0200, Marcelo Tosatti:
>> > Implement KVM hypercalls for the guest
>> > to issue frequency changes.
>> >
>> > Current situation with DPDK and frequency changes is as
On Fri, Feb 03, 2017 at 05:43:50PM +0100, Radim Krcmar wrote:
> 2017-02-02 15:47-0200, Marcelo Tosatti:
> > Implement KVM hypercalls for the guest
> > to issue frequency changes.
> >
> > Current situation with DPDK and frequency changes is as follows:
> > An algorithm in the guest decides when to
On Fri, Feb 03, 2017 at 05:43:50PM +0100, Radim Krcmar wrote:
> 2017-02-02 15:47-0200, Marcelo Tosatti:
> > Implement KVM hypercalls for the guest
> > to issue frequency changes.
> >
> > Current situation with DPDK and frequency changes is as follows:
> > An algorithm in the guest decides when to
2017-02-02 15:47-0200, Marcelo Tosatti:
> Implement KVM hypercalls for the guest
> to issue frequency changes.
>
> Current situation with DPDK and frequency changes is as follows:
> An algorithm in the guest decides when to increase/decrease
> frequency based on the queue length of the device.
2017-02-02 15:47-0200, Marcelo Tosatti:
> Implement KVM hypercalls for the guest
> to issue frequency changes.
>
> Current situation with DPDK and frequency changes is as follows:
> An algorithm in the guest decides when to increase/decrease
> frequency based on the queue length of the device.
On Thursday, February 02, 2017 03:47:55 PM Marcelo Tosatti wrote:
> Implement KVM hypercalls for the guest
> to issue frequency changes.
>
> Current situation with DPDK and frequency changes is as follows:
> An algorithm in the guest decides when to increase/decrease
> frequency based on the
On Thursday, February 02, 2017 03:47:55 PM Marcelo Tosatti wrote:
> Implement KVM hypercalls for the guest
> to issue frequency changes.
>
> Current situation with DPDK and frequency changes is as follows:
> An algorithm in the guest decides when to increase/decrease
> frequency based on the
Implement KVM hypercalls for the guest
to issue frequency changes.
Current situation with DPDK and frequency changes is as follows:
An algorithm in the guest decides when to increase/decrease
frequency based on the queue length of the device.
On the host, a power manager daemon is used to listen
Implement KVM hypercalls for the guest
to issue frequency changes.
Current situation with DPDK and frequency changes is as follows:
An algorithm in the guest decides when to increase/decrease
frequency based on the queue length of the device.
On the host, a power manager daemon is used to listen
32 matches
Mail list logo
