Re: [linux-lvm] Discussion: performance issue on event activation mode

From: Peter Rajnoha <prajnoha@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "bmarzins@redhat.com" <bmarzins@redhat.com>,
	"zkabelac@redhat.com" <zkabelac@redhat.com>,
	"teigland@redhat.com" <teigland@redhat.com>,
	"linux-lvm@redhat.com" <linux-lvm@redhat.com>,
	Heming Zhao <heming.zhao@suse.com>
Subject: Re: [linux-lvm] Discussion: performance issue on event activation mode
Date: Wed, 29 Sep 2021 23:53:15 +0200	[thread overview]
Message-ID: <20210929215315.o73j3qiewon63hqi@alatyr-rpi.brq.redhat.com> (raw)
In-Reply-To: <9947152f39a9c5663abdbe3dfee343556e8d53d7.camel@suse.com>

On Tue 28 Sep 2021 06:34, Martin Wilck wrote:
> Hello David and Peter,
> 
> On Mon, 2021-09-27 at 10:38 -0500, David Teigland wrote:
> > On Mon, Sep 27, 2021 at 12:00:32PM +0200, Peter Rajnoha wrote:
> > > > - We could use the new lvm-activate-* services to replace the
> > > > activation
> > > > generator when lvm.conf event_activation=0.  This would be done by
> > > > simply
> > > > not creating the event-activation-on file when event_activation=0.
> > > 
> > > ...the issue I see here is around the systemd-udev-settle:
> > 
> > Thanks, I have a couple questions about the udev-settle to understand
> > that
> > better, although it seems we may not need it.
> > 
> > >   - the setup where lvm-activate-vgs*.service are always there (not
> > >     generated only on event_activation=0 as it was before with the
> > >     original lvm2-activation-*.service) practically means we always
> > >     make a dependency on systemd-udev-settle.service, which we
> > > shouldn't
> > >     do in case we have event_activation=1.
> > 
> > Why wouldn't the event_activation=1 case want a dependency on udev-
> > settle?
> 
> You said it should wait for multipathd, which in turn waits for udev
> settle. And indeed it makes some sense. After all: the idea was to
> avoid locking issues or general resource starvation during uevent
> storms, which typically occur in the coldplug phase, and for which the
> completion of "udev settle" is the best available indicator.
> 

Udevd already limits the number of concurent worker processes
processing the udev rules for each uevent. So even if we trigger all the
uevents, they are not processed all in parallel, there's some queueing.

However, whether this is good or not depends on perspective - you could
have massive paralelism and a risk of resource starvation or, from the
other side, you could have timeouts because something wasn't processed
in time for other parts of the system which are waiting for dependencies.

Also, the situation might differ based on the fact whether during the
uevent processing we're only looking at that concrete single device for
which we've just received an event or whether we also need to look at
other devices.

-- 
Peter

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/