From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: [PATCH 0/4] xen: sched / cpupool: fixes and
 improvements, mostly for when suspend/resume is involved
Date: Thu, 25 Jun 2015 14:15:04 +0200
Message-ID: <20150625103457.3353.39292.stgit@Solace.station>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin.df@gmail.com>) id 1Z863j-0001AC-VI
	for xen-devel@lists.xenproject.org; Thu, 25 Jun 2015 12:15:12 +0000
Received: by wiga1 with SMTP id a1so162577644wig.0
	for <xen-devel@lists.xenproject.org>;
	Thu, 25 Jun 2015 05:15:08 -0700 (PDT)
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>, Sisu Xi <xisisu@gmail.com>, George Dunlap <george.dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Robert VanVossen <robert.vanvossen@dornerworks.com>, Josh Whitehead <josh.whitehead@dornerworks.com>, Meng Xu <mengxu@cis.upenn.edu>, Jan Beulich <JBeulich@suse.com>, Ben Guthro <ben@guthro.net>
List-Id: xen-devel@lists.xenproject.org

This is mostly about fixing bugs showing up during suspend/resume, with "non
default" configurations such as, pCPUs free from any cpupool, more than one
cpupool in the system, etc.

I tried a few different appoaches, for dealing with these cases. For instance,
I tried creating an 'idle cpupool', and then putting the free pCPUs there,
instead than sort-of parking them in cpupool0 (although in a special
condition), like we're doing now, but that introduces other issues.  I think
this series is, the least invasive, and yet correct, way of dealing with the
situation.

In some more detail:
 * patch 1 is just refactoring/beautifying dump output;
 * patch 2 is the fix for a bug showing up during resume, when two or more
   cpupools exist;
 * patch 3 fixes a bug (in the suspend/resume path again) and also improves
   Credit1 behavior, i.e., stops it from considering pCPUs that are outside
   of any pool as potential candidates where to execute vCPUs;
 * patch 4 is refactoring again, with the intent of making what made patch
   3 necessary less likely to happen! :-)

Thanks and Regards,
Dario
---
Dario Faggioli (4):
      xen: sched: avoid dumping duplicate information
      xen: x86 / cpupool: clear the proper cpu_valid bit on pCPU teardown
      xen: credit1: properly deal with pCPUs not in any cpupool
      xen: sched: get rid of cpupool_scheduler_cpumask()

 xen/arch/x86/smpboot.c      |    1 -
 xen/common/cpupool.c        |    8 +++++---
 xen/common/domain.c         |    5 +++--
 xen/common/domctl.c         |    4 ++--
 xen/common/sched_arinc653.c |    2 +-
 xen/common/sched_credit.c   |   27 ++++++++++++++++++---------
 xen/common/sched_rt.c       |   12 ++++++------
 xen/common/sched_sedf.c     |    5 +++--
 xen/common/schedule.c       |   20 ++++++++++++++------
 xen/include/xen/sched-if.h  |   12 ++++++++++--
 10 files changed, 62 insertions(+), 34 deletions(-)

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)