On Fri, May 18, 2018 at 07:18:57PM +0200, Paolo Bonzini wrote:
> On 18/05/2018 19:13, Eduardo Habkost wrote:
> >> As much as we'd like to be helpful and validate input, you need a real
> >> time host too. I'm not sure how we'd find out - I suggest we do not
> >> bother for now.
> > I'm worried that
On 18/05/2018 19:13, Eduardo Habkost wrote:
>> As much as we'd like to be helpful and validate input, you need a real
>> time host too. I'm not sure how we'd find out - I suggest we do not
>> bother for now.
> I'm worried that people will start enabling the flag in all kinds
> of scenarios where th
On 18/05/2018 18:04, Eduardo Habkost wrote:
>> Without mlock you should always use pv spinlocks.
>>
>> Otherwise you risk blocking on a lock taken by
>> a VCPU that is in turn blocked on IO, where the IO
>> is not completing because CPU is being used up
>> spinning.
>
> So the stronger guarantee se
On Fri, May 18, 2018 at 08:01:49PM +0300, Michael S. Tsirkin wrote:
> On Fri, May 18, 2018 at 01:04:31PM -0300, Eduardo Habkost wrote:
> > CCing qemu-devel, as I'm now discussing userspace.
> >
> > On Thu, May 17, 2018 at 10:55:33PM +0300, Michael S. Tsirkin wrote:
> > > On Thu, May 17, 2018 at 03
On Fri, May 18, 2018 at 01:04:31PM -0300, Eduardo Habkost wrote:
> CCing qemu-devel, as I'm now discussing userspace.
>
> On Thu, May 17, 2018 at 10:55:33PM +0300, Michael S. Tsirkin wrote:
> > On Thu, May 17, 2018 at 03:46:58PM -0300, Eduardo Habkost wrote:
> > > On Thu, May 17, 2018 at 05:54:24P
CCing qemu-devel, as I'm now discussing userspace.
On Thu, May 17, 2018 at 10:55:33PM +0300, Michael S. Tsirkin wrote:
> On Thu, May 17, 2018 at 03:46:58PM -0300, Eduardo Habkost wrote:
> > On Thu, May 17, 2018 at 05:54:24PM +0300, Michael S. Tsirkin wrote:
> > > HINTS_DEDICATED seems to be somewh
On Fri, May 18, 2018 at 11:41:23AM +0200, Paolo Bonzini wrote:
> On 17/05/2018 20:46, Eduardo Habkost wrote:
> > My understanding of the original patch is that the intention is
> > to tell the guest that it is very unlikely to be preempted, so it
> > can choose a more appropriate spinlock implement
On 17/05/2018 20:46, Eduardo Habkost wrote:
> My understanding of the original patch is that the intention is
> to tell the guest that it is very unlikely to be preempted, so it
> can choose a more appropriate spinlock implementation. This
> description implies that the guest will never be preempt
On Thu, May 17, 2018 at 03:46:58PM -0300, Eduardo Habkost wrote:
> On Thu, May 17, 2018 at 05:54:24PM +0300, Michael S. Tsirkin wrote:
> > HINTS_DEDICATED seems to be somewhat confusing:
> >
> > Guest doesn't really care whether it's the only task running on a host
> > CPU as long as it's not pree
On Thu, May 17, 2018 at 05:54:24PM +0300, Michael S. Tsirkin wrote:
> HINTS_DEDICATED seems to be somewhat confusing:
>
> Guest doesn't really care whether it's the only task running on a host
> CPU as long as it's not preempted.
>
> And there are more reasons for Guest to be preempted than host
On 17/05/2018 16:54, Michael S. Tsirkin wrote:
> HINTS_DEDICATED seems to be somewhat confusing:
>
> Guest doesn't really care whether it's the only task running on a host
> CPU as long as it's not preempted.
>
> And there are more reasons for Guest to be preempted than host CPU
> sharing, for ex
11 matches
Mail list logo
