On Tue, 2020-03-03 at 11:32 +0100, Miklos Szeredi wrote: > On Tue, Mar 3, 2020 at 11:22 AM Steven Whitehouse < > swhiteho@xxxxxxxxxx> wrote: > > Hi, > > > > On 03/03/2020 09:48, Miklos Szeredi wrote: > > > On Tue, Mar 3, 2020 at 10:26 AM Miklos Szeredi <miklos@xxxxxxxxxx > > > > wrote: > > > > On Tue, Mar 3, 2020 at 10:13 AM David Howells < > > > > dhowells@xxxxxxxxxx> wrote: > > > > > Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > > > > > > I'm doing a patch. Let's see how it fares in the face of > > > > > > all these > > > > > > preconceptions. > > > > > Don't forget the efficiency criterion. One reason for going > > > > > with fsinfo(2) is > > > > > that scanning /proc/mounts when there are a lot of mounts in > > > > > the system is > > > > > slow (not to mention the global lock that is held during the > > > > > read). > > > BTW, I do feel that there's room for improvement in userspace > > > code as > > > well. Even quite big mount table could be scanned for *changes* > > > very > > > efficiently. l.e. cache previous contents of > > > /proc/self/mountinfo and > > > compare with new contents, line-by-line. Only need to parse the > > > changed/added/removed lines. > > > > > > Also it would be pretty easy to throttle the number of updates so > > > systemd et al. wouldn't hog the system with unnecessary > > > processing. > > > > > > Thanks, > > > Miklos > > > > > > > At least having patches to compare would allow us to look at the > > performance here and gain some numbers, which would be helpful to > > frame > > the discussions. However I'm not seeing how it would be easy to > > throttle > > updates... they occur at whatever rate they are generated and this > > can > > be fairly high. Also I'm not sure that I follow how the > > notifications > > and the dumping of the whole table are synchronized in this case, > > either. > > What I meant is optimizing current userspace without additional > kernel > infrastructure. Since currently there's only the monolithic > /proc/self/mountinfo, it's reasonable that if the rate of change is > very high, then we don't re-read this table on every change, only > within a reasonable time limit (e.g. 1s) to provide timely updates. > Re-reading the table on every change would (does?) slow down the > system so that the actual updates would even be slower, so throttling > in this case very much makes sense. Optimizing user space is a huge task. For example, consider this (which is related to a recent upstream discussion I had): https://blog.janestreet.com/troubleshooting-systemd-with-systemtap/ Working on improving libmount is really useful but that can't help with inherently inefficient approaches to keeping info. current which is actually needed at times. > > Once we have per-mount information from the kernel, throttling > updates > probably does not make sense. And can easily lead to application problems. Throttling will lead to an inability to have up to date information upon which application decisions are made. I don't think it's a viable solution to the separate problem of a large number of notifications either. Ian
