Re: Discussion: performance issue on event activation mode

On Thu, Sep 30, 2021 at 07:22:29AM +0000, Martin Wilck wrote:
> On Wed, 2021-09-29 at 23:39 +0200, Peter Rajnoha wrote:
> > For event-based activation, I'd expect it to really behave in event-
> > based manner, that is, to respond to events as soon as they come and not
> > wait for all the other devices unnecessarily.
> 
> I may be missing something here. Perhaps I misunderstood David's
> concept. Of course event-based activation is best - in theory.
> The reason we're having this discussion is that it may cause thousands
> of event handlers being executed in parallel, and that we have seen
> cases where this was causing the system to stall during boot for
> minutes, or even forever. The ideal solution for that would  be to
> figure out how to avoid the contention, but I thought you and David had
> given up on that.
> 
> Heming has shown that the "static" activation didn't suffer from this
> problem. So, to my understanding, David was seeking for a way to
> reconcile these two concepts, by starting out statically and switching
> to event-based activation when we can without the risk of stalling. To
> do that, we must figure out when to switch, and (like it or not) udev
> settle is the best indicator we have.
> 
> Also IMO David was striving for a solution that "just works"
> efficiently both an small and big systems, without the admin having to
> adjust configuration files.

Right, this is not entirely event based any longer, so there could be some
advantage of an event-based system that we sacrifice.  I think that will
be a good tradeoff for the large majority of cases, and will make a good
default.

> > The use of udev-settle is always a pain - for example, if there's a mount
> > point defined on top of an LV, with udev-settle as dependency, we practically
> > wait for all devices to settle. With 'all', I mean even devices which are not
> > block devices and which are not event related to any of that LVM
> > layout and the stack underneath. So simply we could be waiting uselessly and we
> > could increase possibility of a timeout (...for the mount point etc.).

One theoretical advantage of an event-based system is that it reacts
immediately, so you get faster results.  In practice it's often anything
but immediate, largely because of extra work and moving parts in the
event-based scheme, processing each event individually.  So, the simpler
non-event-based method will often be faster I think, and more robust (all
the moving parts are where things break, so best to minimize them.)

You've filled in some interesting details about udev-settle for me, and it
sounds like there are some ideas forming about an alternative, which would
offer us a better way to switch to event-base-mode.  I'd like to be able
to simply replace the systemd-udev-settle dependency with an improved
"new-settle" dependency when that's ready.

Dave

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