Date: Tue, 6 Jul 1999 13:03:15 -0400 (EDT) From: Dan Seguin <dseg@texar.com> To: Ladavac Marino <mladavac@metropolitan.at> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG> Subject: RE: Connect and so on.. Message-ID: <Pine.BSF.4.05.9907061241330.11807-100000@pak2.texar.com> In-Reply-To: <55586E7391ACD211B9730000C11002761796D2@r-lmh-wi-100.corpnet.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907061241330.11807-100000>