Re: Boot time and 3 sec in warning_print

[Julien Grall <julien@xxxxxxx>]

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?

Cheers,

--
Julien Grall