kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: yezengruan <yezengruan@huawei.com>
Cc: joelaf@google.com, linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	suleiman@google.com, will@kernel.org,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted
Date: Mon, 17 Aug 2020 13:25:05 +0100	[thread overview]
Message-ID: <cbcfb402b7fdb8a2a45b80fbb0e79f3e@kernel.org> (raw)
In-Reply-To: <fe72592c-c721-bece-1469-95eebf931299@huawei.com>

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 
>>> 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 assumes that 
>>> VCPU
>>> is available:
>>> 
>>>       wake_up_process()
>>>        try_to_wake_up()
>>>         select_task_rq_fair()
>>>          available_idle_cpu()
>>>           vcpu_is_preempted()    // return false;
>>> 
>>> Which is, obviously, not the case.
>>> 
>>> This RFC patch set adds a simple vcpu_is_preempted() implementation 
>>> so
>>> that scheduler can make better decisions when it search for the idle
>>> (v)CPU.
>> Hi,
>> 
>> A gentle ping.
>> 
>> 	-ss
>> _______________________________________________
>> kvmarm mailing list
>> kvmarm@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>> .
> 
> Hi Sergey,
> 
> I have a set of patches similar to yours.
> 
> https://lore.kernel.org/lkml/20191226135833.1052-1-yezengruan@huawei.com/

It really isn't the same thing at all. You are exposing PV spinlocks,
while Sergey exposes preemption to vcpus. The former is a massive,
and probably unnecessary superset of the later, which only impacts
the scheduler (it doesn't change the way locks are implemented).

You really shouldn't conflate the two (which you have done in your
series).

         M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2020-08-17 12:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21  4:17 [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted Sergey Senozhatsky
2020-07-21  4:17 ` [RFC][PATCH 1/4] arm64:kvm: define pv_state SMCCC HV calls Sergey Senozhatsky
2020-07-21  4:17 ` [RFC][PATCH 2/4] arm64: add guest pvstate support Sergey Senozhatsky
2020-07-21  4:17 ` [RFC][PATCH 3/4] arm64: add host " Sergey Senozhatsky
2020-07-21  4:17 ` [RFC][PATCH 4/4] arm64: do not use dummy vcpu_is_preempted() anymore Sergey Senozhatsky
2020-08-17  2:03 ` [RFC][PATCH 0/4] arm64:kvm: teach guest sched that VCPUs can be preempted Sergey Senozhatsky
2020-08-17 12:03   ` yezengruan
2020-08-17 12:25     ` Marc Zyngier [this message]
2020-08-17 14:15       ` yezengruan
2020-09-11  8:58       ` Sergey Senozhatsky
2020-12-08 20:02         ` Joel Fernandes
2020-12-09  9:43           ` Marc Zyngier
2020-12-10  1:39             ` Joel Fernandes
2020-12-10  8:45               ` Marc Zyngier
2020-12-11  9:34                 ` Quentin Perret
2020-12-16  1:45                   ` Joel Fernandes
2020-09-11  8:46     ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cbcfb402b7fdb8a2a45b80fbb0e79f3e@kernel.org \
    --to=maz@kernel.org \
    --cc=joelaf@google.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=suleiman@google.com \
    --cc=will@kernel.org \
    --cc=yezengruan@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).