Re: Boot time and 3 sec in warning_print

[Julien Grall <julien@xxxxxxx>]

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
> > LiveUpdating.
> >
> > 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.
Cheers,

--
Julien Grall