Hi Juergen,
I've found another regression that happens only with sched-gran=core.
CentOS 5.11 (PV, CPUs: 32; RAM: 6GB) kernel hangs during suspend attempt.
The last kernel messages are:
CPU 1 offline: Remove Rx thread
CPU 2 offline: Remove Rx thread
Kernel: Linux localhost
On 24.07.19 16:54, Sergey Dyasli wrote:
On 24/07/2019 10:13, Juergen Gross wrote:
The fix is a one-liner. :-)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index f0bc5b3161..da9efb147f 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -2207,6 +2207,7 @@ static
On 24/07/2019 10:13, Juergen Gross wrote:
> The fix is a one-liner. :-)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index f0bc5b3161..da9efb147f 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -2207,6 +2207,7 @@ static struct sched_unit
>
On 22.07.19 16:22, Sergey Dyasli wrote:
On 19/07/2019 14:57, Juergen Gross wrote:
I have now a git branch with the two problems corrected and rebased to
current staging available:
github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
On 19/07/2019 14:57, Juergen Gross wrote:
> I have now a git branch with the two problems corrected and rebased to
> current staging available:
>
> github.com/jgross1/xen.git sched-v1b
Many thanks for the branch! As for the crashes, vcpu_sleep_sync() one
seems to be fixed now. But I can still
On 18.07.19 17:14, Sergey Dyasli wrote:
On 18/07/2019 15:48, Juergen Gross wrote:
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC]
On 16.07.19 17:45, Sergey Dyasli wrote:
On 05/07/2019 14:17, Sergey Dyasli wrote:
[2019-07-05 00:37:16 UTC] (XEN) [24907.482686] Watchdog timer detects that
CPU30 is stuck!
[2019-07-05 00:37:16 UTC] (XEN) [24907.514180] [ Xen-4.13.0-8.0.6-d x86_64
debug=y Not tainted ]
[2019-07-05
On 19.07.19 07:41, Juergen Gross wrote:
On 18.07.19 17:14, Sergey Dyasli wrote:
On 18/07/2019 15:48, Juergen Gross wrote:
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely
On 18.07.19 17:14, Sergey Dyasli wrote:
On 18/07/2019 15:48, Juergen Gross wrote:
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC]
On Thu, 2019-07-18 at 16:14 +0100, Sergey Dyasli wrote:
> On 18/07/2019 15:48, Juergen Gross wrote:
> >
> > I can easily reproduce the issue with any PV guest with more than 1
> > vcpu
> > by doing "xl save" and then "xl restore" again.
> >
> > With the reproducer being available I'm now diving
On 18/07/2019 15:48, Juergen Gross wrote:
> On 15.07.19 16:08, Sergey Dyasli wrote:
>> On 05/07/2019 14:56, Dario Faggioli wrote:
>>> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660]
On 15.07.19 16:08, Sergey Dyasli wrote:
On 05/07/2019 14:56, Dario Faggioli wrote:
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
1) This crash is quite likely to happen:
[2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
that CPU2 is stuck!
[2019-07-04 18:22:46
On 05/07/2019 14:17, Sergey Dyasli wrote:
> [2019-07-05 00:37:16 UTC] (XEN) [24907.482686] Watchdog timer detects that
> CPU30 is stuck!
> [2019-07-05 00:37:16 UTC] (XEN) [24907.514180] [ Xen-4.13.0-8.0.6-d
> x86_64 debug=y Not tainted ]
> [2019-07-05 00:37:16 UTC] (XEN)
On 05/07/2019 14:56, Dario Faggioli wrote:
> On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
>> 1) This crash is quite likely to happen:
>>
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
>> that CPU2 is stuck!
>> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.226293]
On Tue, 2019-05-28 at 12:32 +0200, Juergen Gross wrote:
> Add support for core- and socket-scheduling in the Xen hypervisor.
>
> [...]
>
> I have done some very basic performance testing: on a 4 cpu system
> (2 cores with 2 threads each) I did a "make -j 4" for building the
> Xen
> hypervisor.
On Fri, 2019-07-05 at 14:17 +0100, Sergey Dyasli wrote:
> 1) This crash is quite likely to happen:
>
> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.220660] Watchdog timer detects
> that CPU2 is stuck!
> [2019-07-04 18:22:46 UTC] (XEN) [ 3425.226293] [ Xen-4.13.0-
> 8.0.6-d x86_64 debug=y Not
On 05.07.19 15:17, Sergey Dyasli wrote:
Hi Juergen,
I did some testing of this series (with sched-gran=core) and posting a couple of
crash backtraces here for your information.
Additionally, resuming a Debian 7 guest after suspend is broken.
I will be able to provide any additional
Hi Juergen,
I did some testing of this series (with sched-gran=core) and posting a couple of
crash backtraces here for your information.
Additionally, resuming a Debian 7 guest after suspend is broken.
I will be able to provide any additional information only after XenSummit :)
1) This crash
Add support for core- and socket-scheduling in the Xen hypervisor.
Via boot parameter sched-gran=core (or sched-gran=socket)
it is possible to change the scheduling granularity from cpu (the
default) to either whole cores or even sockets.
All logical cpus (threads) of the core or socket are
19 matches
Mail list logo
