[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Boot time and 3 sec in warning_print

Hi Jan,

On 15/02/2021 12:29, Jan Beulich wrote:
On 15.02.2021 11:50, Julien Grall wrote:
On 15/02/2021 10:41, Jan Beulich wrote:
On 15.02.2021 11:35, Julien Grall wrote:
On 15/02/2021 08:38, Jan Beulich wrote:
On 15.02.2021 09:13, Jürgen Groß wrote:
On 15.02.21 08:37, Anders Törnqvist wrote:
I would like to shorten the boot time in our system if possible.

In xen/common/warning.c there is warning_print() which contains a 3
seconds loop that calls  process_pending_softirqs().

What would the potential problems be if that loop is radically shortened?

A user might not notice the warning(s) printed.

But I can see your point. I think adding a boot option for setting
another timeout value (e.g. 0) would do the job without compromising
the default case.

I don't think I agree - the solution to this is to eliminate the
reason leading to the warning.
The delay is intentionally this way
to annoy the admin and force them to take measures.
Given they are warning, an admin may have assessed them and considered
there is no remediation necessary.

We encountered the same problem with LiveUpdate. If you happen to have a
warning (e.g. sync_console for debugging), then you are adding 3s in
your downtime (this can more than double-up the actual one).

One very explicitly should not run with sync_console in production.

I knew it would be misinterpreted ;). I agree that sync_console must not
be used in production.

I gave the example of sync_console because this is something impacting
debugging of LiveUpdate. If you have a console issue and need to add
sync_console, then you may end up to wreck completely your platform when

Without the 3s delay, then you have a chance to LiveUpdate and figure
out the problem.

I'm afraid I don't see how LU comes into the picture here: We're
talking about a boot time delay. The delay doesn't recur at any
point at runtime.

Live Update is a reboot of the hypervisor. The main difference is we are carrying the state of each domain states to the new Xen along with some strictly necessary global state (e.g. IOMMU).

So the new Xen will mostly followed the same boot path as you would from a "classic" (re)boot. There are only a few twist necessary for LiveUpdate (e.g. reserving memory, creating/restoring multiple domains).

We would need to gate the 3s pause in the case of LiveUpdate. At which point, it seems we may want to take an approach that also benefits other users.


Julien Grall



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.