Hello,
This series implement soft-affinity for Credit2. Or, at least, it implements
most of it.
In fact, these patches introduces soft-affinity support in the scheduler,
everywhere it is needed, with the exception of the load balancer. This is
because I think load balancing should be
In fact, we want to be able to use them from any scheduler.
While there, make the moved code use 'v' for struct_vcpu*
variable, like it should be done everywhere.
No functional change intended.
Signed-off-by: Dario Faggioli
Signed-off-by: Justin T. Weaver
We want to find the runqueue with the least average load,
and to do that, we scan through all the runqueues.
It is, therefore, enough that, during such scan:
- we identify the runqueue with the least load, among
the ones that have pcpus that are part of the soft
affinity of the vcpu we're
This run is configured for baseline tests only.
flight 71572 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71572/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 21
>>> On 16.06.17 at 15:34, wrote:
> Assuming answers are 'no' and 'yes', I think I'd leave
> cpu_is_haltable() as it is
Agreed, you analysis was quite helpful.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
Hello,
Any comments for this series?
Thanks,
Petre
On Ma, 2017-05-30 at 12:46 +0300, Petre Pircalabu wrote:
> This patchset enables masking the reception of write_ctrlreg events
> depending
> on the value of certain bits in that register.
> The most representative example is filtering out
>>> On 24.05.17 at 08:56, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -82,6 +82,7 @@ static int vmx_vmfunc_intercept(struct cpu_user_regs *regs);
> struct vmx_pi_blocking_vcpu {
> struct list_head list;
> spinlock_t
flight 71574 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71574/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
Paul Durrant examined a VM after a migration failure and found it
short of free space with some essential services not running, and
conjectures that this is cauxed by disk shortage.
Signed-off-by: Ian Jackson
CC: Paul Durrant
---
>>> On 16.06.17 at 17:28, wrote:
> On Fri, Jun 16, 2017 at 9:15 AM, Jan Beulich wrote:
> On 16.06.17 at 16:26, wrote:
>>> On Tue, May 30, 2017 at 3:46 AM, Petre Pircalabu
>>> wrote:
Add support
Hi Julien,
On 06/15/2017 09:53 PM, Julien Grall wrote:
> Hi Sergej,
>
> On 06/15/2017 12:05 PM, Sergej Proskurin wrote:
>> In this commit we make the p2m_* helpers, which access PTE properties in
>> a simplified way, publicly available. This is due to the fact that the
>> helpers will be used in
>>> On 16.06.17 at 08:48, wrote:
> The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> we would wrongly use 00:00.0 to search VT-d unit.
>
> To search VT-d unit for a VF, the BDF of the PF is used. And If the
> PF is an Extended Function, the BDF of one
On Fri, Jun 16, 2017 at 9:33 AM, Jan Beulich wrote:
On 16.06.17 at 17:28, wrote:
>> On Fri, Jun 16, 2017 at 9:15 AM, Jan Beulich wrote:
>> On 16.06.17 at 16:26, wrote:
On Tue, May 30, 2017 at 3:46 AM,
flight 110492 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110492/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12
Ian Jackson writes ("[OSSTEST PATCH 3/4] dhcp leases: Introduce new
client/server leases query mechanism"):
> * A Python program `ms-leases-omapiproxy' which speaks OMAPI to the
>DHCP server, and a simple synchronous query protocol on its
>stdin/stdout. OMAPI authentication is based on
On Fri, 16 Jun 2017, Dario Faggioli wrote:
> On Thu, 2017-06-15 at 13:14 -0700, Stefano Stabellini wrote:
> > On Thu, 15 Jun 2017, Volodymyr Babchuk wrote:
> > > Hello Stefano,
> > > On 15 June 2017 at 21:21, Stefano Stabellini
> > > wrote:
> > > > Would you be up for
201 - 216 of 216 matches
Mail list logo