[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 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 LiveUpdating.

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

What was just an "annoyance" for boot can now completely wreck your
guests and system (not many software can tolerate large downtime).

So I think we either want to drop the 3s pause completely or allow the
user to decide whether he/she cares about it via a command line option.

I am leaning towards the former at the moment.

I'm afraid I'm -2 towards complete removal. I'm at least -1 towards
shortening of the pause, as already indicated.
So how do you suggest to approach the issues I discussed above?


Julien Grall



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