bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fs_notify patch


From: Marcus Brinkmann
Subject: Re: fs_notify patch
Date: Wed, 26 Jun 2002 00:01:18 -0400
User-agent: Mutt/1.3.25i

On Tue, Jun 25, 2002 at 11:30:41PM -0400, Roland McGrath wrote:
> Oh, I thought you liked the MACH_SEND_NOTIFY plan.  

I do, and I will use it for the file changes.

I think the only part of my patch that is related to and in
contradiction with MACH_SEND_NOTIFY is the send timeout.
The tickno is actually required for clients to notice if they were skipped
(the only reason I don't need it for my console so far is that I have
the shared memory area to pass the information to the clients).
The simpleroutine is required in any case for the server not to block.
The fs_notify_t is wholly unrelated to this question.

So, the question is if we want servers by default to use a send timeout
or a MACH_SEND_NOTIFY strategy.  Well, the first thing to note is that
the send timeout is a magnitude easier to implement for the servers:
MiG already does (almost) the right thing with the patch and the server
side doesn't change much at all.  To get MACH_SEND_NOTIFY right, you
have a lot of overhead in the server, and it is not trivial to get it
right, in particular in case the node goes away while you are in a
pending notifications.  I mentioned some of the problems in my mail
related to the console server.  I am using MACH_SEND_NOTIFY there, and
will continue to do so.  But for diskfs, for now, I don't see a reason
why we should change it.  Maybe when Moritz and Wolfgang start to stress
the diskfs notify interface, and notice a lot of gaps in the tickno, we
can take another look at it.  But I don't think it is much of a problem for
another year or two.

That said, I don't really object against changing diskfs to use
MACH_SEND_NOTIFY as well.  But I would rather apply my patch now
and continue with console development, and put "MiG support for
notify port and implement this in diskfs" on a task list somewhere,
rather than doing the mig and diskfs work now.  The additional advantage
is that we can play around with the notify port stuff in the console
server and see how it works, and develop a reference implementation
there first, and then port it over to libdiskfs at a later time.

> Using a zero timeout, a nonresponsive receiver stays on the list and causes
> the server a system call for the failed message-send attempt every time
> there is a new change. 

My measurements didn't show much of a slowdown even with 85000 system
calls of this type compared to the running time of 50s.  And this is the
pathological case where a server is constantly much faster than the client
over a long period of time.

Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]