branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-multivcpu
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Hello,
As anticipated here:
https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg02052.html
Here's a preliminary version of my work, trying to implement
core-scheduling in Xen.
First of all, this deals with Credit1 only. I have patches for Credit2,
and I've been working on having
For scalability reasons, we keep track of the number of runnable vcpu
in each runqueue (there is one runq for each pcpu). This, right now,
includes running both runnable and running ones.
Change the mechanism so that we count runnable only runnable ones,
which is more useful. In fact, we want to
Currently, if a pcpu is idle and has some runnable vcpus in its
runqueue, the other pcpus (e.g., when they're going idle) never try to
steal any of such runnable vcpus.
This is because Credit1 assumes that, when a vcpu wakes up, if the pcpu
on which it is queued is idle, that very pcpu is
If a vcpu wakes up on an idle pcpu, we always (try to) run it there.
This may seem ok but it may actually be not, in case there is another
(also idle) pcpu which would be better suited (for load balancing and/or
affinity reasons, for instance) to run it.
So, instead than blindly tickle the pcpu
Basically, for dealing earlier with the case when there are some idle
pcpus that are suitable for running the newly waking vcpu (and bailing
out if not).
This is pure code refactoring, with the purpose of separating code
movement and functional changes (coming in follow-up commits).
Introduced in 9bb9c73884d "xen: credit2: implement true
SMT support", it was available only to Credit2.
Move the functions to common headers so that also other
schedulers can use them, to track the idleness of full
cores.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc:
As in Credit2, We add a per-scheduler cpumask in which, the bits od
the CPUs of a core are set if and only if all the threads of the core
are idle.
If even just one thread is not idle (or has just been tickled and hence
is about to pick up work), all the bits are zero.
Note that this new mask
If sched_smt_cosched is enabled, after having selected the next vcpu to
run on a pcpu, we check whether either:
- the whole core is fully idle,
- or the chosen vcpu is from the same domain than the other vcpus
running on pcpus of the core.
If that is not the case, and the core is not idle, we
This is pure code refactoring, with the purpose of isolating code
movement. No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git
flight 126473 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126473/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-baroque1 2 hosts-allocate broken REGR. vs. 125522
On 08/24/2018 04:48 AM, Wei Liu wrote:
On Fri, Aug 24, 2018 at 10:25:49AM +, osstest service owner wrote:
flight 126429 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 126472 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-start fail REGR. vs. 126042
flight 126545 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126545/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 16973234fc60a95daf7be32ee89123914fdab3f0
baseline version:
ovmf
flight 126535 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126535/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-amd64-xen-freebsd 7 xen-build-freebsdfail never pass
version targeted for testing:
vcpu_deassign() has only one caller: _vcpu_remove().
Let's consolidate the two functions into one.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_null.c | 76 ++-
1 file changed, 35
xen: sched: support vcpu hotplug/hotunplug in the 'null scheduler'
Hello,
It turned out, while discussing this patch:
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00249.html
that the 'null scheduler' does not really support vcpu
hotplug/hotunplug. In fact, under some
If a pCPU has been/is being offlined, we don't want it to be neither
assigned to any pCPU, nor in the wait list.
So, avoid doing that while inserting or migrating vcpus.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Stefano Stabellini
Cc: Roger Pau Monne
---
On Tue, Aug 21, 2018 at 02:41:06AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > --- a/xen/arch/x86/mm/shadow/multi.c
> > +++ b/xen/arch/x86/mm/shadow/multi.c
> > @@ -2926,18 +2926,25 @@ static int sh_page_fault(struct vcpu *v,
> > }
> > else
> >
On Tue, Aug 21, 2018 at 02:27:40AM -0600, Jan Beulich wrote:
> >>> On 17.08.18 at 17:12, wrote:
> > @@ -423,6 +426,10 @@ const struct x86_emulate_ops *shadow_init_emulation(
> > ? sizeof(sh_ctxt->insn_buf) : 0;
> >
> > return _shadow_emulator_ops;
> > +#else
> > +BUG();
> > +
In fact, we want to be able to enforce that only vcpus belonging to the
same domain are executed on pcpus that are part of one core (i.e., that
are 'siblings hyperthread', or just 'hyperthreads').
To achieve that, we introduce a new new data structure, representing a
physical core, and use it to
Now that we have the information about which cores are fully idle, use
it for tickling pcpus.
This way, if there are cores that are fully idle, we tickle a pcpu from
one of them. This improve the SMT-awareness of the scheduler,
guaranteeing a better distribution of load, right from vcpu wakeup.
If sched_smt_cosched is enabled, when poking at other pcpus' runqueues
(for doing load balancing), we only consider the vcpus of the domain
that is running on the core already. Unless the core is fully idle, in
which case, we can pick up any vcpu.
Signed-off-by: Dario Faggioli
---
Cc: George
If SMT domain co-scheduling is enabled, we only migrate a vcpu to either
a fully idle core, or to pcpus of cores where other vcpus of the same
domain are running already.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit.c | 17 ++---
1 file changed,
If sched_smt_cosched is enabled, take it into account when choosing on
what pcpu to run a vcpu (e.g., for doing a migration).
Basically, we can only run vcpus of domain A on pcpus of cores where
other vcpus of domain A are running already (and, vice versa, we
absolutely don't want to run a vcpu
Introduce some new event, related to SMT-aware domain co-scheduling,
in Credit1 code, and their handling and parsing in xenalyze.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
---
TODO:
- deal with xentrace_format.
---
tools/xentrace/xenalyze.c | 74
When a vcpu which is exclusively pinned to a pcpu wakes up, we only have
one option: tickling that exact pcpu.
If sched_smt_cosched is enabled, however, it only makes sense to do that
if pcpu is in a core where vcpus of the domain are running already.
Signed-off-by: Dario Faggioli
---
Cc:
If sched_smt_cosched is enabled, when tickling pcpus (upon vcpu
wakeups), take into account the fact that only pcpus of cores where
other vcpus of the same domain are running already, or fully idle ones,
will actually be able to pick the vcpu up.
*NB* there are places where the behavior needs a
On 24/08/18 20:43, Jason Andryuk wrote:
> On Wed, Aug 15, 2018 at 10:39 AM Juergen Gross wrote:
>>
>> On 15/08/18 16:10, Jan Beulich wrote:
>> On 15.08.18 at 15:17, wrote:
2) 32bit PV guests which use writeable pagetable support will
automatically get shadowed when the clear the
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
It is all the time that we call vcpu_deassing() that the vcpu _must_ be
assigned to a pCPU, and hence that such pCPU can't be free.
Therefore, move the ASSERT-s which check for these properties in that
function, where they belong better.
---
Cc: George Dunlap
---
xen/common/sched_null.c |5
If a pCPU has been/is being offlined, we don't want it to be neither
assigned to any pCPU, nor in the wait list.
Therefore, when we detect that a vcpu is going offline, remove it from
both places.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Stefano Stabellini
Cc: Roger Pau Monne
When a vcpu that was offline, comes back online, we do want it to either
be assigned to a pCPU, or go into the wait list.
So let's do exactly that. Detecting that a vcpu is coming back online is
a bit tricky. Basically, if the vcpu is waking up, and is neither
assigned to a pCPU, nor in the wait
On Fri 24-08-18 13:43:16, Christian König wrote:
> Am 24.08.2018 um 13:32 schrieb Michal Hocko:
> > On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> > > Two more worries for this patch.
> > >
> > >
> > >
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > > > +++
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++
On Fri 24-08-18 13:57:52, Christian König wrote:
> Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
> > > That won't work like this there might be multiple
> > > invalidate_range_start()/invalidate_range_end() pairs open at the same
> > >
Versions of linux privcmd prior to commit dc9eab6fd94d ("return -ENOTTY
for unimplemented IOCTLs") will return -EINVAL rather than the conventional
-ENOTTY for unimplemented codes. This breaks the error path in
libxenforeignmemory resource mapping, which only translates ENOTTY into
EOPNOTSUPP to
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
That won't work like this there might be multiple
invalidate_range_start()/invalidate_range_end()
On Fri 24-08-18 14:18:44, Christian König wrote:
> Am 24.08.2018 um 14:03 schrieb Michal Hocko:
> > On Fri 24-08-18 13:57:52, Christian König wrote:
> > > Am 24.08.2018 um 13:52 schrieb Michal Hocko:
> > > > On Fri 24-08-18 13:43:16, Christian König wrote:
> > [...]
> > > > > That won't work like
On Wed, Aug 22, 2018 at 10:45:34AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 09:51:58AM +0200, Roger Pau Monne wrote:
> > Returns all the memory types applicable to a page.
> >
> > This function is unimplemented for ARM.
> >
> > Signed-off-by: Roger Pau Monné
> > Reviewed-by: Jan Beulich
flight 75115 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75115/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-jessie-netboot-pvgrub 19 guest-start/debian.repeat fail
REGR. vs. 75078
On 07/30/2018, 10:18 AM, Xiao Liang wrote:
> On 07/29/2018 11:30 PM, David Miller wrote:
>> From: Xiao Liang
>> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>
>>> @@ -1330,6 +1331,11 @@ static struct net_device
>>> *xennet_create_dev(struct xenbus_device *dev)
>>> netif_carrier_off(netdev);
>>>
On 24/08/18 13:12, Jiri Slaby wrote:
> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
>> On 07/29/2018 11:30 PM, David Miller wrote:
>>> From: Xiao Liang
>>> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>>
@@ -1330,6 +1331,11 @@ static struct net_device
*xennet_create_dev(struct xenbus_device
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
> Two more worries for this patch.
>
>
>
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> > @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> > *
> > * @amn: our notifier
> >
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*
*
flight 126429 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/126429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
On Wed, Aug 22, 2018 at 10:45:28AM +0100, Wei Liu wrote:
> On Wed, Aug 22, 2018 at 09:51:57AM +0200, Roger Pau Monne wrote:
> > Introduce a new dom0-iommu=map-inclusive generic option that
> > supersedes iommu_inclusive_mapping. The previous behavior is preserved
> > and the option should only be
On Fri, Aug 24, 2018 at 10:25:49AM +, osstest service owner wrote:
> flight 126429 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/126429/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
Signed-off-by: Wei Liu
---
tools/firmware/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index ed1a1318f6..cf304fc578 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -15,7 +15,7 @@
Two more worries for this patch.
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
> @@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
> *
> * @amn: our notifier
> */
> -static void amdgpu_mn_read_lock(struct amdgpu_mn *amn)
>
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
[...]
> > --- a/mm/hmm.c
> > +++ b/mm/hmm.c
> > @@ -177,16 +177,19 @@ static void hmm_release(struct mmu_notifier *mn,
> > struct mm_struct *mm)
> > up_write(>mirrors_sem);
> > }
> >
> > -static void hmm_invalidate_range_start(struct
101 - 151 of 151 matches
Mail list logo
