From: Tim Chen <tim.c.chen@linux.intel.com>
To: Subhra Mazumdar <subhra.mazumdar@oracle.com>,
linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Subject: Re: Gang scheduling
Date: Fri, 12 Oct 2018 11:01:42 -0700 [thread overview]
Message-ID: <c08136ad-3e68-ce1c-af03-b591acc582fc@linux.intel.com> (raw)
In-Reply-To: <44347e72-d595-5c2d-3983-7237526c71c6@oracle.com>
On 10/10/2018 05:09 PM, Subhra Mazumdar wrote:
> Hi,
>
> I was following the Coscheduling patch discussion on lkml and Peter mentioned he had a patch series. I found the following on github.
>
> https://github.com/pdxChen/gang/commits/sched_1.23-loadbal
>
> I would like to test this with KVMs. Are the commits from 38d5acb to f019876 sufficient? Also is there any documentaion on how to use it (any knobs I need to turn on for gang scheduling to happen?) or is it enabled by default for KVMs?
>
> Thanks,
> Subhra
>
I would suggest you try
https://github.com/pdxChen/gang/tree/sched_1.23-base
without the load balancing part of gang scheduling.
It is enabled by default for KVMs.
Due to the constant change in gang scheduling status of the QEMU thread
depending on whether vcpu is loaded or unloaded,
the load balancing part of the code doesn't work very well.
The current version of the code need to be optimized further. Right now
the QEMU thread constantly does vcpu load and unload during VM enter and exit.
We gang schedule only after vcpu load and register the thread to be gang
scheduled. When we do vcpu unload, the thread is removed from the set
to be gang scheduled. Each time there's a synchronization with the
sibling thread that's expensive.
However, for QEMU, there's a one to one correspondence between the QEMU
thread and vcpu. So we don't have to change the gang scheduling status
for such thread to avoid the church and sync with the sibling. That should
be helpful for VM with lots of I/O causing constant VM exits. We're
still working on this optimization. And the load balancing should be
better after this change.
Tim
next prev parent reply other threads:[~2018-10-12 18:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 0:09 Subhra Mazumdar
2018-10-12 18:01 ` Tim Chen [this message]
2018-10-15 22:49 ` Subhra Mazumdar
2019-02-13 2:57 ` Subhra Mazumdar
2019-02-13 18:25 ` Tim Chen
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=c08136ad-3e68-ce1c-af03-b591acc582fc@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=subhra.mazumdar@oracle.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
all inboxes | Powered by JetHome®