Choi
>
> Reviewed-by: Stewart Hildebrand
>
Ok, cool, there were versions of these series that my filters did miss,
and that's why I replied to v1. :-/
Well, scratch that email, and sorry for the noise.
Regards,
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualizati
se according to my knowledge of periodic real-time scheduling.
I think the patch can have my:
Acked-by: Dario Faggioli
With the only caveat that I don't have any specific knowledge or
experience with the details of the ARINC653 algorithms, and hence I
cannot tell for sure whether or not the new
> ---
> > MAINTAINERS | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6ba7d2765f..cc40c0be9d 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -490,6 +490,7 @@ F: xen/common/sched/rt.c
hall use the same
> > names
> > and type qualifiers").
> >
> > No functional changes.
> >
> > Signed-off-by: Federico Serafini
>
> Reviewed-by: Stefano Stabellini
>
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario
On Mon, 2023-07-31 at 14:40 -0700, Stefano Stabellini wrote:
> George, Dario,
>
> Please ack
>
Looks good to me.
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://
On Thu, 2023-05-18 at 17:27 -0400, Stewart Hildebrand wrote:
> On 5/5/23 01:59, Juergen Gross wrote:
> > >
> > > Signed-off-by: Stewart Hildebrand
> >
> > Reviewed-by: Juergen Gross
>
> Thanks for the review. Does this still need a maintainer ac
On Fri, 2022-10-21 at 12:39 +0200, Juergen Gross wrote:
> Instead of directly falling back to the idle unit in case the top
> unit from the run queue happened to be not runnable, consult the run
> queue again.
>
> Suggested-by: Dario Faggioli
> Signed-off-by: Juergen Gross
&g
? 0 : notifier_to_errno(notifier_rc);
>
> Simplify the use cases by moving the handling of the success case
> into
> the functions.
>
> Signed-off-by: Juergen Gross
> ---
> ...
> xen/common/sched/core.c | 2 +-
> xen/common/sched/cpupool.c |
ed: don't disable scheduler on cpus
> during suspend")
> Signed-off-by: Juergen Gross
> Tested-by: Marek Marczykowski-Górecki
>
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https:/
On Fri, 2022-10-07 at 13:17 +0200, Juergen Gross wrote:
> On 07.10.22 12:32, Mykyta Poturai wrote:
> >
> > Signed-off-by: Juergen Gross
>
> I can't remember having written this patch. The one I remember was
> for
> x86.
>
> > Reviewed-by: Dario Faggiol
ct and should be applied, no matter what the
outcome of this subthread will be. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
407e7772 ("xen/sched: introduce unit_runnable_state()")
> Signed-off-by: Juergen Gross
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
0b04 ("xen: sched: simplify ACPI S3 resume path.")
>
> This Fixes: tag is wrong. It should be:
>
> Fixes: 8a04eaa8ea83 ("xen/sched: move some per-vcpu items to struct
> sched_unit")
>
Acked-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about
nsive test, but just dom0 was enough to crash it before, and
> it
> stays working now.
>
That's very cool to hear! Thanks for testing and reporting back.
Just to be sure, did you check both Credit1 and Credit2 and do they
both work, with Juergen's patch?
Thanks again and
On Wed, 2022-08-03 at 08:19 +0200, Jan Beulich wrote:
> On 02.08.2022 18:08, Dario Faggioli wrote:
> > > ... for it to be strictly only Dom0, you want to check d-
> > > >domain_id
> > > here.
> > >
> > Ok, I'll send an update that does tha
user changes the hard-affinity.
And this could result in the vCPUs behaving differently than what the
user wanted and expects.
Fixes: dafd936dddbd ("Make credit2 the default scheduler")
Reported-by: Olaf Hering
Signed-off-by: Dario Faggioli
Reviewed-by: Jan Beulich
---
Cc: Jan Be
If dom0_vcpus_pin is used, make sure the pinning is only done for
dom0 vcpus, instead of for the hardware domain (which might not be
dom0 at all!).
Suggested-by: Jan Beulich
Signed-off-by: Dario Faggioli
Reviewed-by: Jan Beulich
---
Cc: George Dunlap
---
Changes from v1:
- check domain_id to
atch 2).
While there, make the dom0_vcpus_pin boot parameter more precise, by
making sure that it is applied only to actual dom0's vCPUs, and not to
the vCPUs of the hardware domain, which may or may not be dom0 itself
(patch 2).
Regards
---
Dario Faggioli (2):
xen: sched: dom0_vcpus_pin should onl
On Tue, 2022-08-02 at 16:56 +0200, Jan Beulich wrote:
> On 02.08.2022 15:51, Dario Faggioli wrote:
> > If dom0_vcpus_pin is used, make sure the pinning is only done for
> > dom0 vcpus, instead of for the hardware domain (which might not be
> > dom0 at all!).
>
> Hmm,
Mmm... this patch has a few hard-tabs in it! Apologies for that. :-/
I'm attaching a version without them, but I surely can resubmit the
series with this fixed, it that's easier.
Regards, and Sorry again
On Tue, 2022-08-02 at 15:51 +0200, Dario Faggioli wrote:
> Right now, affi
user changes the hard-affinity.
And this could result in the vCPUs behaving differently than what the
user wanted and expects.
Fixes: dafd936ddd ("Make credit2 the default scheduler")
Reported-by: Olaf Hering
Signed-off-by: Dario Faggioli
---
Cc: Jan Beulich
Cc: George Dunlap
---
Ch
If dom0_vcpus_pin is used, make sure the pinning is only done for
dom0 vcpus, instead of for the hardware domain (which might not be
dom0 at all!).
Suggested-by: Jan Beulich
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
Difference from "RFC" [1]:
- new patch
rdware domain, which may or may not be dom0 itself
(patch 2).
Regards
---
Dario Faggioli (2):
xen: sched: dom0_vcpus_pin should only affect dom0
xen/sched: setup dom0 vCPUs affinity only once
xen/common/sched/core.c | 63 +
1 file changed,
it, re-test it and send
it before disappearing for a couple of weeks for vacations...
Sorry it's taking so long.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Lab
On Fri, 2022-04-29 at 14:16 +0200, Jan Beulich wrote:
> On 29.04.2022 12:52, Dario Faggioli wrote:
> > > Is that mainly
> > > to have a way to record preferences even when all preferred CPUs
> > > are
> > > offline, to be able to go back to the preferences
On Wed, 2022-04-13 at 12:00 +0200, Jan Beulich wrote:
> On 12.04.2022 18:11, Dario Faggioli wrote:
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -572,11 +572,41 @@ int sched_init_vcpu(struct vcpu *v)
> > }
> >
> > /*
&
viewed-by: Juergen Gross
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.a
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> + else if ( is_hardware_domain(d) )
> + {
> + /*
> + * In absence of dom0_vcpus_pin, the hard and soft affinity
> of
> + * domain-0 is controlled by the dom0_nodes parameter. At
> this p
On Tue, 2022-04-12 at 16:11 +, Dario Faggioli wrote:
> On Tue, 2022-04-12 at 15:48 +0000, Dario Faggioli wrote:
> > On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> >
> >
> > And while doing that, I think we should consolidate touching the
> > affinity
On Tue, 2022-04-12 at 15:48 +, Dario Faggioli wrote:
> On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
>
>
> And while doing that, I think we should consolidate touching the
> affinity only there, avoiding altering it twice. After all, we
> already
> know how it
On Fri, 2022-04-08 at 14:36 +0200, Jan Beulich wrote:
> On 08.04.2022 13:20, Dario Faggioli wrote:
> > On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> > > Credit2 moving the vCPU-s off of their initially assigned ones
> > > right
> > > away of course
On Fri, 2022-04-08 at 11:20 +, Dario Faggioli wrote:
> On Thu, 2022-04-07 at 15:27 +0200, Jan Beulich wrote:
> >
> > Credit2 moving the vCPU-s off of their initially assigned ones
> > right
> > away of course renders sched_select_initial_cpu()'s use of
&g
; > xen/common/boot_cpupools.c or xen/common/boot-cpupools.c
> > >
> >
> > ... this one may want living there are well.
>
> Yes I agree with you all, I will rename it to xen/common/sched/boot-
> cpupool.c
> and add it in MAINTAINERS.
>
FWIW, I agree as well
instead of calling sched_set_affinity(), we call
vcpu_set_affinity().
I'm therefore wondering if we should try to just do that... But I'm not
sure, mostly because that would mean calling
domain_update_node_affinity() for all dom0
m
> parts
> Acked-by: Jan Beulich
> Tested-by: Téo Couprie Diaz
>
Acked-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
e occasion to replace open coded scheduler search with the
> new static function in scheduler_init.
>
> Signed-off-by: Luca Fancellu
> Reviewed-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Sof
the code, and I appreciate that it's not trivial and
that it's probably impossible to achieve 100% decoupling (at least not
without adding a lot more complexity)... But any step we can make in
that direction would be, IMO, a
ve Cc-ed Marek, because I think I've read that
QubesOS that it does on QubesOS, but I'm not sure if the situation
is the same...
- if it's working, how?
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dari
nfig@entry=0x7fe721df11b0, domid=domid@entry=0x7fe721df10a8,
ao_how=ao_how@entry=0x0, aop_console_how=aop_console_how@entry=0x7fe721df10f0)
at libxl_create.c:2075
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
This change should be backpor
On Mon, 2022-01-17 at 15:56 +, Anthony PERARD wrote:
> On Fri, Jan 14, 2022 at 11:22:00PM +0000, Dario Faggioli wrote:
> >
> > Also, if we go that way, I guess we want to change
> > libxl_cputopology_list_free(), libxl_pcitopology_list_free(),
> &g
l.
> And wouldn't that be a problem for PV guests, too?
>
Yeah, that's one of the things that makes it tricky
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
On Thu, 2022-01-13 at 12:05 +, Anthony PERARD wrote:
> On Wed, Jan 12, 2022 at 05:41:36PM +0100, Dario Faggioli wrote:
>
> > 2) there should be nothing to free anyway
>
> The issue here is that it doesn't appear to be true. Even if "info"
> is
> NU
could not do that
yet.
So, if anyone wants to help with this, handing over suggestions for
potential good spots, that would help a lot.
Alternatively, we can submit the series as ARM-only... But I fear that
the x86 side of things would then be easily forgotten. :-(
Thanks again a
On Wed, 2022-01-12 at 17:41 +0100, Dario Faggioli wrote:
> It is possible to encounter a segfault in libxl during concurrent
> domain
> create and destroy operations.
>
> This is because Placement of existing domains on the host's CPUs is
> examined
> when creating a ne
tinfo() or
xc_vcpu_getaffinity() will start to fail, and we return back to the
caller inconsistent information, such as a NULL list of vcpus, but a
modified and not 0 any longer, number of vcpus in the list.
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Jue
If libxl_vcpu_list() returned NULL, we should not call
libxl_numainfo_list_free() as:
1) it'll fail trying to (double) free() *list
2) there should be nothing to free anyway
Signed-off-by: Dario Faggioli
Tested-by: James Fehlig
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
turns NULL as the list of them.
Regards
---
Dario Faggioli (2):
tools/libs/light: numa placement: don't try to free a NULL list of vcpus
tools/libs/light: don't touch nr_vcpus_out if listing vcpus and returning
NULL
tools/libs/light/libxl_domain.c | 14 --
t
Signed-off-by: Daniel P. Smith
> ---
> xen/arch/x86/cpu/vpmu.c | 2 +-
> xen/common/domctl.c | 2 +-
> xen/common/sched/core.c | 4 ++--
> xen/include/xen/sched.h | 5 +
>
The */sched* bits:
Acked-by: Dario Faggioli
But with a strong preference for renaming
is_system_d
e-lakeside-output-xl_vcpu-list
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
fnptr targets
> > x86/aepi: Annotate fnptr targets
> > x86/psr: Annotate fnptr targets
> > x86/dpci: Annotate fnptr targets
> > x86/pt: Annotate fnptr targets
> > x86/time: Annotate fnptr targets
> > x86/misc: Annotate fnptr targets
> > x86/s
On Mon, 2021-09-27 at 09:51 +0200, Jan Beulich wrote:
> On 24.09.2021 16:51, Dario Faggioli wrote:
> > On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> >
> > > There is one buggy race record, TRC_RTDS_BUDGET_BURN. As it must
> > > remain
> >
t;
> Signed-off-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Rais
f-by: Andrew Cooper
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
sig
t;
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
r
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<>
endering
> which was absent previously.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
a nested tb_init_done check, which is dropped. (The optimiser
> also spotted
> this, which is why it doesn't manifest as a binary difference.)
> * All HVMTRACE_?D() change to TRACE() as cycles is explicitly
> skipped.
>
> Signed-off-by: Andrew Cooper
>
R
On Tue, 2021-09-21 at 13:03 +0200, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
> >
> > Signed-off-by: Andrew Cooper
>
> Like for v1: Largely
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
> One remark:
>
> > @@ -717,9 +713,
g them in
just one field and decode the information in xentrace.
Of course, I can send a patch for that myself, even as a followup of
this series when it's in, as soon as we agree about the best way
forward.
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualiz
* TODO: truncation? */ in place so
> whomever
> encounters weird behaviour from this trace record has a bit more help
> of
> where to look?
>
Sure, that's fine for me.
Thanks and Regards
--
Dario Faggioli, P
gt;
> Fix that by tolerating vcpus not being allocated yet.
>
> Fixes: 70fadc41635b9b6 ("xen/cpupool: support moving domain between
> cpupools with different granularity")
> Reported-by: Bertrand Marquis
> Signed-off-by: Juergen Gross
>
Reviewed-by: Dario Faggioli
-by: Juergen Gross
> Tested-by: Marek Marczykowski-Górecki
>
>
Mmm... This is an interesting one. In fact, this fix is not only
correct, it's also simple, effective and (I guess) easy enough to
backport.
Considering all these things together with the fact that we have an
open iss
null_unit_remove(), called by sched_destroy_vcpu().
And I agree that the unit should be offline, but null_unit_remove()
calls unit_deassign() only if the unit *is* online, so... What's going
on? :-/
Regards
--
Dario Faggioli, Ph.
, it's entirely possible that I'm missing something obvious here, but
what it is that is making you think that we're in null_unit_migrate() ?
Does that come from a different instance of this WARN() ?
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-08-05 at 08:31 +0200, Jan Beulich wrote:
> On 04.08.2021 19:55, Dario Faggioli wrote:
> >
> > Suggested-by: George Dunlap
> > Signed-off-by: Dario Faggioli
>
> In part based on your explanation in response to my v1 comments:
> Reviewed-by: Jan Beulic
during the runqueue scan, does not have enough budget for being run,
we should continue looking instead than giving up and picking the idle
unit.
Suggested-by: George Dunlap
Signed-off-by: Dario Faggioli
Cc: George Dunlap
Cc: Jan Beulich
---
Changes from v1:
* fixed the patch tags and some st
On Wed, 2021-08-04 at 17:13 +0200, Jan Beulich wrote:
> On 04.08.2021 15:28, Dario Faggioli wrote:
> >
> > So, was it this you were asking about and, if yes, does this answer
> > your concerns?
>
> Yes, it does.
>
Ok, great. :-)
> I continue to think though tha
On Wed, 2021-08-04 at 09:37 +0200, Jan Beulich wrote:
> On 03.08.2021 19:36, Dario Faggioli wrote:
> >
> > Signed-off-by: Dario Faggioli
> > Suggested-by: George Dunlap
>
> Minor remark: Generally I think the order of tags should follow the
> timeline: Suggestion
("xen: credit2:
implement utilization cap") and in 34f2ad1 ("xen: credit2: use
non-atomic cpumask and bit operations").
Suggested-by: Juergen Gross
Signed-off-by: Dario Faggioli
Cc: George Dunlap
Cc: Jan Beulich
---
This patch is only necessary for branches older than 4.
On Tue, 2021-08-03 at 19:36 +0200, Dario Faggioli wrote:
> It should, therefore, be backported and applied to all the branches
> to
> which that commit has been. About backports, it should be
> straigthforward to do that until 4.13.
>
> For 4.12 and earlier, it's trickie
Err... of course, the "pli" and "bla" stuff between the [] are a
leftover of some experiments that I had to do with `stg email`, due to
mail handling changes, and should really not have been there in this
email...
Sorry. :-/
On Tue, 2021-08-03 at 19:36 +0200, Dario Fagg
during the runqueue scan, does not have budget to be executed, we
should continue looking instead than giving up and picking the idle
unit.
Signed-off-by: Dario Faggioli
Suggested-by: George Dunlap
Cc: George Dunlap
Cc: Jan Beulich
---
This is necessary to completely fix the bug that was descri
Hi George (and sorry for the delay in replying),
On Mon, 2021-06-07 at 12:10 +, George Dunlap wrote:
> > On May 28, 2021, at 4:12 PM, Dario Faggioli
> > wrote:
> > Reported-by: Michał Leszczyński
> > Reported-by: Dion Kant
> > Signed-off-by: Dario Faggioli
On Tue, 2021-04-27 at 10:35 +0200, Jan Beulich wrote:
> On 19.03.2021 13:14, Dario Faggioli wrote:
> >
> > ---
> > Cc: George Dunlap
> > Cc: Ian Jackson
> > ---
> > Despite the limited effect, it's a bug. So:
> > - it should be backported;
>
n the runq
scanning function.
Reported-by: Michał Leszczyński
Reported-by: Dion Kant
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Michał Leszczyński
Cc: Dion Kant
---
This is a bugfix and it solves the following problems, reported in
various ways:
* https://lists.xen.or
; Clearly with the shim defaulting to it, SCHED_NULL must be supported at
> least there.
>
> Signed-off-by: Jan Beulich
> Acked-by: Roger Pau Monné
>
Reviewed-by: Dario Faggioli
> ---
> v2: Also drop SCHED_NULL setting from defconfig. Make SCHED_NULL the
> default when PV_SH
On Thu, 2021-05-20 at 14:55 +0100, Anthony PERARD wrote:
> On Tue, May 18, 2021 at 05:24:30PM +0200, Dario Faggioli wrote:
> >
> > I think we need the following commit in our QEMU: bbd2d5a812077
> > ("build: -no-pie is no functional linker flag").
>
> Hi
.. /usr/bin/perl
configure: creating ./config.status
So, what am I missing or doing wrong?
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
On Wed, 2021-05-19 at 08:28 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 06:42:45PM +0200, Dario Faggioli wrote:
> > Fix the build inside our openSUSE Tumbleweed container by using
> > adding libzstd headers. While there, remove the explicit dependency
> > for pyth
umbleweed, therefore:
> > Signed-off-by: Costin Lupu
>
> Reviewed-by: Julien Grall
>
Tested-by: Dario Faggioli
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
Fix the build inside our openSUSE Tumbleweed container by using
adding libzstd headers. While there, remove the explicit dependency
for python and python3 as the respective -devel packages will pull
them in anyway.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
Acked-by: Roger Pau Monné
---
Cc: Doug Goldstein
Cc: Andrew Cooper
---
Ch
at in containerize already, through the DOCKER_CMD variable)
to the local building of the containers as well.
Thanks and Regards
---
Dario Faggioli (2):
automation: use DOCKER_CMD for building containers too
automation: fix dependencies on openSUSE Tumbleweed containers
automation/build
On Tue, 2021-05-18 at 16:33 +0200, Dario Faggioli wrote:
> On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> > On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > > From: Dario Faggioli
> > >
> Mmm... this email address does not really ex
cedb8e6f6e192d36199ca9fde5841
Feel free to use it as a base, or tell me if I can help more with it in
any other way with it.
Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
On Tue, 2021-05-18 at 16:26 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:07PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
> > Use DOCKER_CMD from the environment (if defined) in the containers'
> > makefile too, so that, e.g., when
On Tue, 2021-05-18 at 15:20 +0200, Roger Pau Monné wrote:
> On Tue, May 18, 2021 at 02:04:13PM +0200, Dario Faggioli wrote:
> > From: Dario Faggioli
> >
Mmm... this email address does not really exist, and it's a mistake
that it ended up here. :-/
> > Fix the
From: Dario Faggioli
Fix the build inside our openSUSE Tumbleweed container by using
the proper python development packages (and adding zstd headers).
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: Andrew Cooper
---
.../build/suse/opensuse
From: Dario Faggioli
Use DOCKER_CMD from the environment (if defined) in the containers'
makefile too, so that, e.g., when doing `export DOCKED_CMD=podman`
podman is used for building the containers too.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Roger Pau Monne
Cc: A
to do that).
While there, extend the generalization of the container runtime to use
(we have that in containerize already, through the DOCKER_CMD variable)
to the local building of the containers as well.
Regards
---
Dario Faggioli (2):
automation: use DOCKER_CMD for building containers too
27;m just saying that we would prefer the plugin to end up in one of
those places, rather than remaining its own project. And of course
we're up for maintaining it, wherever it lands. :-)
> We are working to make sure that the API for KernelShark plugins
> remains
> stable, so your plu
igning a color to
each vCPU.
This is pretty much arbitrary and can be changed, but it of course has
to be something that we can extract from from the trace event records
or, at least, from the trace file (e.g., as Andrew said, we do have
per-VM UUIDs, but they're currently not there).
Regards
d t3. And "glued" on top of it, there will be
a 'CPU 5' plot which will have, say, a blue box between t1 and t2 and a
yellow box between t2 and t3.
As for the KVM case, the CPU plots will tell you on what physical CPU
d0v5 runs. While the special 'CPU 5' plot that is &quo
hat is currently implemented in the trace-cmd
patches (but not KVM specific one). For synch'ing the Xen trace with
them, well, I don't really know... We'd have to think about it. :-P
> Perhaps we can do something like that with Xen as well.
>
Would be awesome, IMO. :-)
Thanks a
On Wed, 2021-04-14 at 19:11 +0100, Andrew Cooper wrote:
> On 14/04/2021 18:31, Dario Faggioli wrote:
> > > A couple of questions. Which Xen libraries do you currently use
> > > map
> > > the
> > > frames?
> > >
> > Err... If I understood t
Xen or KS sources...
And I'll now leave any further comments to Giuseppe himself. :-)
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
--
st due to the fact that we wanted to let the Xen and
KernelShark communities know about this work as soon as Giuseppe got it
working properly and reliably, to gather any kind of feedback, decide
where this should live, in the long run, (in Xen? In KS? In its own
project?), etc. :-)
ll):
>
Oh, wow... Sorry about that. I was sure I had checked (and with gcc10),
but clearly I'm wrong.
> [...]
>
> Re-instate a special form of for_each_cpu(), experimentally "proven"
> to
> avoid the diagnostics.
>
> Signed-off-by: Jan Beulich
>
Review
On Thu, 2021-03-18 at 19:11 +0100, Dario Faggioli wrote:
> On Mon, 2021-03-15 at 12:18 +, Ian Jackson wrote:
>
> >
> > https://bugzilla.opensuse.org/show_bug.cgi?id=1179246
> >
> So, this is mostly about the third issue, the one described in the
> openSU
100%)
(XEN) 8: [0.7] flags=2 cpu=0 credit=9991815 [w=256] load=262144 (~100%)
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
---
Despite the limited effect, it's a bug. So:
- it should be backported;
- I think it should be included in 4.15. The risk is pretty low,
1 - 100 of 791 matches
Mail list logo
