On Tue, 6 Jul 1999, Ladavac Marino wrote:
> [ML] Regardless of userland/kernel daemon implementation, the
> real bottleneck is going to be the network latency. Do not expect
> anything under a millisecond (compared to that, the daemon rescheduling
> latency of a couple of microseconds is really negligible).
Of course. We knew the network latency would be the problem from the
beginning. But the rescheduling might be an issue when a sufficient amount
of request caching has been achieved.
>
> > One can easily imagine the processes being blocked starting to backup,
> > since the comm daemon is competing for processor time, even if every
> > entry
> > into the kernel by (arbitrary) tracked syscalls resets the priority of
> > the
> > comms daemon to a higher level. (I'm trying to let the daemon get as
> > much
> > of the processor as possible to complete what it is doing. It releases
> > it's quanta whenever it needs to wait for something).
> [ML] They will backup, since all of them will be waiting on
> I/O. But it will not be because the authentication daemon is starving
> them of CPU.
You're right, but that's not what I was thinking. I guess I didn't state
it very clearly. What I meant to convey was this: since the processes are
blocked awaiting authentication, they cannot proceed until the comm server
receives a response. They are not being starved because of the daemon,
they were explicitly turned "off" until such a time as the daemon can
instruct the kernel to unblock them. In essence, I want to make sure that
the daemon is made to wait as little as possible for whatever reason, be
it pre-emption, or resource allocation. It'll be waiting long enough on
the network.
In effect, you will have a machine with *really*really*
> slow syscalls. A more feasible proof of concept would be a table driven
> authenticator which lives in kernel and provides a syscall for table
> update. Then, you could call this authentication from a syscall gate
> glue. One could even imagine a KLD which replaces the syscall table
> with the authentication table and then calls the original entries. The
> mainframe practice shows that the auth entries remain pretty static.
This is essentially what I've done. Replaced syscalls with a flow through
syscall of my own. Couple this with the caching mentioned in the previous
post and we'll get to a point where the request may never need to go
further than the local table. If an entry is not chached, then the comm
daemon will unevitably have to pass it on to the central server.
>
> > Is there an easier/better/more effecient subsystem to use that I don't
> > know about?
> >
> > There are a lot of timing issues here, and I'm sure I've missed some.
> > The
> > comms daemon becomes a huge bottleneck for the processes that happen
> > to
> > make syscalls that are being tracked, but I don't see a better way.
> [ML] Don't use one. The RPC and the network latency will kill
> you.
*sigh*. I know, I know...
> [ML] Do you have to go outside at all is the relevant question.
>
Yes.
> > Also, if someone can point me to some books/papers/soliloquies of how
> > to
> > effeciently manage a shared table, I'd be grateful.
> [ML] IBM probably has loads of documentation on the topic of
> kernel enforced syscall authentication.
>
> /Marino
Thanks! You've been a great help and sounding board.
Dan Seguin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message