On 9/21/05, chas williams - CONTRACTOR <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>,Tom Keiser writes: > >Have you ever taken a close look at FetchData_RXStyle in > >afsfileprocs.c? Did you notice how it calls readv(); rx_Writev() in a > >tight loop? Did it ever occur to you that this is horribly > >inefficient? What is the kernel disk io scheduler doing when we're > >busy in a sendmsg() syscall? If it actually bothers to do something, > > the fileserver is threaded. i would call it somewhat similar to > an nfs file server. several threads are waiting for requests. when > one is busy the others are free to handle requests. thus the tuning > for number of nfsd's in early servers. >
ok. well, I was talking about the latency for one call. sure, we're doing a pretty good job of parallelizing multiple calls. I was simply trying to point out that the latency for a single call to complete could be made lower through added parallelism and asynchrony. > >No. Optimal read-ahead knowledge does not exist, courtesy of the > >halting problem. Of course, the fileserver's kernel knows less than > > the fileserver basically knows how much a client has requested and that > it can only fulfill a certain fixed amount per fetchdata. if the client > made a request bigger than this fixed amount, i suppose the fileserver > could read and cache that amount from the file the knowing that the > client will just ask for the rest. i suppose you could just read the > "right" amount anyway and rely on your operating system's disk block > caching to keep the data available for subsequent calls. > Yeah. It will take a lot of research and prototype development to know for sure whether buffering, cache, aio, or any combination of them give sufficient performance improvements for a "general" workload to justify the increase in code compexity. I'm not trying to claim that any particular solution is going to offer us the holy grail of performance. I just wanted to gauge people's reactions to making the fileserver more complicated and asynchronous. -- Tom Keiser [EMAIL PROTECTED] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
