mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: Christoph Hellwig <hch@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	linux-kernel@vger.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH] xen: wait up to 5 minutes for device connection
Date: Mon, 06 Jul 2009 09:43:19 +0200	[thread overview]
Message-ID: <4A51AB17.5050404@redhat.com> (raw)
In-Reply-To: <15093.1246720530@turing-police.cc.vt.edu>

On 07/04/09 17:15, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 03 Jul 2009 23:21:35 +0200, Gerd Hoffmann said:
>
>> Usually it is *much* faster, but when the host is quite loaded it can
>> take a unusual long time.  With 10 seconds it happends in practice now
>> and then that a virtual machine fails to boot just because the virtual
>> root disk didn't show up fast enough.
>
> Are people actually trying to boot a guest on a host machine so loaded that
> disks take that long to show up - and expect things to work in any sane
> matter?

Even on machines which can handle their load just fine under normal 
circumstances you may see that behavior in case of load peaks.  Booting 
a bunch of virtual machines at the same time can trigger it for example.

> I'm tempted to suggest that booting under conditions like that is almost
> deserving of its own kernel Tainted flag.  If devices aren't showing up in
> a timely manner, we probably need to be leery of any other kernel timeout
> values as well...

It is pointless to taint just because of a unusual delay at some random 
point in time.  A virtual machine can see higher delays due to load 
peaks on the host anytime.  The flag wouldn't carry any useful information.

You could add TAINT_VIRT to flag *all* vm guests, but as the boot log 
gives you that information already it is pointless too IMHO.

cheers,
   Gerd


  reply	other threads:[~2009-07-06  7:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-03 13:12 Paolo Bonzini
2009-07-03 13:28 ` Ian Campbell
2009-07-03 16:00 ` Christoph Hellwig
2009-07-03 21:21   ` Gerd Hoffmann
2009-07-04 15:15     ` Valdis.Kletnieks
2009-07-06  7:43       ` Gerd Hoffmann [this message]
2009-07-06 21:54 ` Jeremy Fitzhardinge
2009-07-08 10:27   ` [PATCH 1/3 v2] xen: fix is_disconnected_device/exists_disconnected_device Paolo Bonzini
2009-07-08 10:27     ` [PATCH 2/3 v2] xen: improvement to wait_for_devices() Paolo Bonzini
2009-07-08 10:27       ` [PATCH 3/3 v2] xen: wait up to 5 minutes for device connetion Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A51AB17.5050404@redhat.com \
    --to=kraxel@redhat.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=hch@infradead.org \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome