Re: fanotify - overall design before I start sending patches

[Pavel Machek <pavel@ucw.cz>]

> > > > Of course, I'm worried about failing to meet this on loaded
> > > > system. And the fact that I _have_ to worry about that means that
> > > > interface is ugly/broken.
> > >
> > > You mean that in 5 seconds, you won't have any point when you can tell
> > > the kernel, "I'm still working"?
> >
> > I have to agree with Pavel here, either you demand the monitor process
> > is RT/mlock and can respond in time, in which case the interface doesn't
> > need a 5 second timeout, or you cannot and you have a hole somewhere.
> >
> > Now having the kernel depend on any user task to guarantee process is of
> > course utterly insane too.
> >
> > Sounds like a bad place to be, and I'd rather not have it.
> >
> > If you really need the intermediate you might as well use a FUSE
> > filesystem, but I suspect there's plenty of problems there as well.
> 
> So you mount FUSE on top of everything if you want to have systemwide 
> monitoring and then you _again_ depend on _userspace_, no? By this logic 
> everything has to be in kernel. But even if it was, and the CPUs are so 
> overloaded that an userspace thread does not get to run at all for X seconds, 
> are kernel threads scheduled differently eg. with priority other than nice 
> levels?

Userspace app not running for 5 seconds != CPU not being available for
5 seconds. I'd worry about swap behaviour here.

> If the timeout is made configurable I think this is the best that can be done 
> here. I don't think the problem is so huge as you are presenting it.

It is ugly. FUSE is more elegant, being already in kernel. Of course,
if your userspace daemon fails, you are doomed, but...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html