Re: Upcoming: Notifications, FS notifications and fsinfo()

[Lennart Poettering]

On Di, 07.04.20 15:59, Miklos Szeredi (miklos@xxxxxxxxxx) wrote:

> On Tue, Apr 7, 2020 at 4:22 AM Ian Kent <raven@xxxxxxxxxx> wrote:
> > > Right now, when you have n mounts, and any mount changes, or one is
> > > added or removed then we have to parse the whole mount table again,
> > > asynchronously, processing all n entries again, every frickin
> > > time. This means the work to process n mounts popping up at boot is
> > > O(nÂ). That sucks, it should be obvious to anyone. Now if we get that
> > > fixed, by some mount API that can send us minimal notifications about
> > > what happened and where, then this becomes O(n), which is totally OK.
>
> Something's not right with the above statement.  Hint: if there are
> lots of events in quick succession, you can batch them quite easily to
> prevent overloading the system.
>
> Wrote a pair of utilities to check out the capabilities of the current
> API.   The first one just creates N mounts, optionally sleeping
> between each.  The second one watches /proc/self/mountinfo and
> generates individual (add/del/change) events based on POLLPRI and
> comparing contents with previous instance.
>
> First use case: create 10,000 mounts, then start the watcher and
> create 1000 mounts with a 50ms sleep between them.  Total time (user +
> system) consumed by the watcher: 25s.  This is indeed pretty dismal,
> and a per-mount query will help tremendously.  But it's still "just"
> 25ms per mount, so if the mounts are far apart (which is what this
> test is about), this won't thrash the system.  Note, how this is self
> regulating: if the load is high, it will automatically batch more
> requests, preventing overload.  It is also prone to lose pairs of add
> + remove in these case (and so is the ring buffer based one from
> David).

We will batch requests too in systemd, of course, necessarily, given
that the /p/s/mi inotify stuff is async. Thing though is that this
means we buy lower CPU usage â working around the O(nÂ) issue â by
introducing artifical higher latencies. We usually want to boot
quickly, and not artificially slow.

Sure one can come up with some super smart scheme how to tweak the
artifical latencies, how to grow them, how to shrink them, depending
on a perceived flood of events, some backing off scheme. But that's
just polishing a turd, if all we want is proper queued change
notification without the O(nÂ) behaviour.

I mean, the fix for an O(nÂ) algorithm is to make it O(n) or so. By
coalescing wake-up events you just lower the n again, probably
linearly, but that still means we pay O(nÂ), which sucks.

Lennart

--
Lennart Poettering, Berlin