Hi Marc, Quentin,
On Fri, Dec 11, 2020 at 4:34 AM Quentin Perret wrote:
>
> On Thursday 10 Dec 2020 at 08:45:22 (+), Marc Zyngier wrote:
> > On 2020-12-10 01:39, Joel Fernandes wrote:
> >
> > [...]
> >
> > > > Quentin and I have discussed potential ways of improving guest
> > > > scheduling
On Thursday 10 Dec 2020 at 08:45:22 (+), Marc Zyngier wrote:
> On 2020-12-10 01:39, Joel Fernandes wrote:
>
> [...]
>
> > > Quentin and I have discussed potential ways of improving guest
> > > scheduling
> > > on terminally broken systems (otherwise known as big-little), in the
> > > form of
On 2020-12-10 01:39, Joel Fernandes wrote:
[...]
Quentin and I have discussed potential ways of improving guest
scheduling
on terminally broken systems (otherwise known as big-little), in the
form of a capacity request from the guest to the host. I'm not really
keen on the host exposing its
Hi Marc, nice to hear from you.
On Wed, Dec 9, 2020 at 4:43 AM Marc Zyngier wrote:
>
> Hi all,
>
> On 2020-12-08 20:02, Joel Fernandes wrote:
> > On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky
> > wrote:
> >>
> >> My apologies for the slow reply.
> >>
> >> On (20/08/17 13:25), Marc Zyngier
Hi all,
On 2020-12-08 20:02, Joel Fernandes wrote:
On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky
wrote:
My apologies for the slow reply.
On (20/08/17 13:25), Marc Zyngier wrote:
>
> It really isn't the same thing at all. You are exposing PV spinlocks,
> while Sergey exposes preemption
On Fri, Sep 11, 2020 at 4:58 AM Sergey Senozhatsky
wrote:
>
> My apologies for the slow reply.
>
> On (20/08/17 13:25), Marc Zyngier wrote:
> >
> > It really isn't the same thing at all. You are exposing PV spinlocks,
> > while Sergey exposes preemption to vcpus.
> >
>
> Correct, we see vcpu
My apologies for the slow reply.
On (20/08/17 13:25), Marc Zyngier wrote:
>
> It really isn't the same thing at all. You are exposing PV spinlocks,
> while Sergey exposes preemption to vcpus.
>
Correct, we see vcpu preemption as a "fundamental" feature, with
consequences that affect scheduling,
Hi,
On (20/08/17 20:03), yezengruan wrote:
> Hi Sergey,
>
> I have a set of patches similar to yours.
>
> https://lore.kernel.org/lkml/20191226135833.1052-1-yezengr...@huawei.com/
I'm sorry for the belated reply.
Right, quite similar, but not exactly, I believe. I deliberately wanted
to
On 2020/8/17 20:25, Marc Zyngier wrote:
> On 2020-08-17 13:03, yezengruan wrote:
>> On 2020/8/17 10:03, Sergey Senozhatsky wrote:
>>> On (20/07/21 13:17), Sergey Senozhatsky wrote:
Hello,
RFC
We noticed that in a number of cases when we wake_up_process()
on
On 2020-08-17 13:03, yezengruan wrote:
On 2020/8/17 10:03, Sergey Senozhatsky wrote:
On (20/07/21 13:17), Sergey Senozhatsky wrote:
Hello,
RFC
We noticed that in a number of cases when we wake_up_process()
on arm64 guest we end up enqueuing that task on a preempted VCPU. The
On 2020/8/17 10:03, Sergey Senozhatsky wrote:
> On (20/07/21 13:17), Sergey Senozhatsky wrote:
>> Hello,
>>
>> RFC
>>
>> We noticed that in a number of cases when we wake_up_process()
>> on arm64 guest we end up enqueuing that task on a preempted VCPU. The culprit
>> appears to be the
On (20/07/21 13:17), Sergey Senozhatsky wrote:
> Hello,
>
> RFC
>
> We noticed that in a number of cases when we wake_up_process()
> on arm64 guest we end up enqueuing that task on a preempted VCPU. The culprit
> appears to be the fact that arm64 guests are not aware of VCPU
Hello,
RFC
We noticed that in a number of cases when we wake_up_process()
on arm64 guest we end up enqueuing that task on a preempted VCPU. The culprit
appears to be the fact that arm64 guests are not aware of VCPU preemption
as such, so when sched picks up an idle VCPU it always
13 matches
Mail list logo
