linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.de>
To: Heming Zhao <heming.zhao@suse.com>, David Teigland <teigland@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] system boot time regression when using lvm2-2.03.05
Date: Tue, 10 Sep 2019 10:01:04 +0200	[thread overview]
Message-ID: <b17fd5db54c852869c7ad8440f3492c367ced33d.camel@suse.de> (raw)
In-Reply-To: <20190909140956.GA31823@redhat.com>

Hi David,

On Mon, 2019-09-09 at 09:09 -0500, David Teigland wrote:
> On Mon, Sep 09, 2019 at 11:42:17AM +0000, Heming Zhao wrote:
> > Hello David,
> > 
> > You are right.  Without calling _online_pvscan_one(), the pv/vg/lv
> > won't be actived.
> > The activation jobs will be done by systemd calling lvm2-
> > activation-*.services later.
> > 
> > Current code, the boot process is mainly blocked by:
> > ```
> > _pvscan_aa
> >   vgchange_activate
> >    _activate_lvs_in_vg
> >     sync_local_dev_names
> >      fs_unlock
> >       dm_udev_wait <=== this point!
> > ```
> 
> Thanks for debugging that.  With so many devices, one possibility
> that
> comes to mind is this error you would probably have seen:
> "Limit for the maximum number of semaphores reached"

Could you explain to us what's happening in this code? IIUC, an
incoming uevent triggers pvscan, which then possibly triggers VG
activation. That in turn would create more uevents. The pvscan process
then waits for uevents for the tree "root" of the activated LVs to be
processed.

Can't we move this waiting logic out of the uevent handling? It seems
weird to me that a process that acts on a uevent waits for the
completion of another, later uevent. This is almost guaranteed to cause
delays during "uevent storms". Is it really necessary?

Maybe we could create a separate service that would be responsible for
waiting for all these outstanding udev cookies?

Martin

  reply	other threads:[~2019-09-10  8:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 13:52 [linux-lvm] system boot time regression when using lvm2-2.03.05 Heming Zhao
2019-08-29 14:37 ` David Teigland
2019-09-03  5:02   ` Heming Zhao
2019-09-03 15:17     ` David Teigland
2019-09-04  8:13       ` Heming Zhao
2019-09-05 12:35         ` Heming Zhao
2019-09-05 16:55           ` David Teigland
2019-09-06  4:31             ` Heming Zhao
2019-09-06  5:01               ` Heming Zhao
2019-09-06  6:51                 ` Martin Wilck
2019-09-06  8:46                   ` Heming Zhao
2019-09-06 14:15                     ` David Teigland
2019-09-06 14:26                     ` David Teigland
2019-09-06 14:03                   ` David Teigland
2019-09-09 11:42                     ` Heming Zhao
2019-09-09 14:09                       ` David Teigland
2019-09-10  8:01                         ` Martin Wilck [this message]
2019-09-10 15:20                           ` David Teigland
2019-09-10 20:38                             ` Zdenek Kabelac
2019-09-11  7:17                               ` Martin Wilck
2019-09-11  9:13                                 ` Zdenek Kabelac
2019-09-12 13:58                                   ` Martin Wilck

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=b17fd5db54c852869c7ad8440f3492c367ced33d.camel@suse.de \
    --to=mwilck@suse.de \
    --cc=heming.zhao@suse.com \
    --cc=linux-lvm@redhat.com \
    --cc=teigland@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;
as well as URLs for NNTP newsgroup(s).